Secure crypto, secure passwords, secure messaging, secure e-mail, secure browsing—we see ‘secure something’ everywhere, but no one defines this term. On closer inspection, ‘secure’ even becomes a catchword most of the time. We discuss these examples in this article.
- The ‘secure’ something
Always stay in the loop!
Subscribe to our RSS/Atom feeds.
The ‘secure’ something
Let’s have a look at different topics and the term “secure” in their context:
Secure cryptographic algorithms
There are at least two golden rules in cryptography:
- Never roll your own cryptography.
- Only use well-known and audited cryptographic algorithms.
We can basically say that “secure” means “unbreakable”. Keep in mind that “secure” in terms of “unbreakable” is relative to the capabilities of an attacker. “Secure” cryptographic algorithms can also become insecure due to technological advance in a few years. For instance, the Data Encryption Standard (DES) was considered “secure” once.
However, even if developers follow the two rules mentioned above, their piece of software using only well-known and audited cryptographic algorithms isn’t automatically secure. A single programming error can render a secure cryptographic algorithm useless.
Therefore, it is important that developers use audited cryptographic libraries and that the whole product (esp. the implementation of cryptography) is audited by a third party. We sometimes see software developers claiming that their app is secure since it uses AES-256 or something like that. Moreover, we see users telling other users that an app is secure because the cryptography in it has been audited. This isn’t sufficient.
Discussing password security is another unpopular topic. Ask 10 different security experts and you get 11 different opinions about password length, complexity and change interval. Some people add fuel to the fire by telling users that even the NIST (National Institute of Standards and Technology) or other agencies don’t recommend to change passwords at all (which isn’t true by the way) or that these people found a magic way to create secure passwords or passphrases.
To keep it simple, there is no “secure” password. A password can be stronger or weaker, but every password can be guessed by using brute force. Moreover, technical progress makes strong passwords weaker over time.
Instead of making your passwords longer and longer and adding more and more different characters or using the latest magic creation formula, you should make use of two-factor authentication if available and stick with a well-known and regularly audited password manager.
The Electronic Frontier Foundation (EFF) published a Secure Messaging Scorecard in 2014. The scorecard consisted of:
- transport encryption
- end-to-end encryption (E2EE)
- verification of identities
- perfect forward secrecy
- proper documentation of the security design
- third-party audits
- recent code audit
In 2018, they tell us that there “is no such thing as a perfect or one-size-fits-all messaging app”, because the scorecard “oversimplified the complex question of how various messengers stack up from a security perspective” and “it wasn’t possible for [the EFF] to clearly describe the security features of many popular messaging apps, in a consistent and complete way, while considering the varied situations and security concerns of [the EFF’s] audience”.
As a result, they didn’t update their scorecard but published a series of articles to discuss the nature of “secure” messaging so users can develop “an understanding of secure messaging that is deeper than a simple recommendation”.
We think “security” means “somewhat encrypted” for most users. However, there is a big difference between encrypted client-server communication and end-to-end encrypted communication, for example. Then, there is optional encryption with unencrypted fallback in some messengers or messengers which store tons of personal data in cleartext on servers making this data vulnerable to admins and server-side attackers.
The EFF also says that an “app with great security features is worthless if none of your friends and contacts use it, and the most popular and widely used apps can vary significantly by country and community.” They argue that E2EE is “great for preventing companies and governments from accessing your messages” but “if someone is worried about a spouse, parent, or employer with physical access to their device, the ability to send ephemeral, ‘disappearing’ messages might be their deciding factor in choosing a messenger”.
To sum up, we can say that there is no one-size-fits-all “secure” messenger. Different users want different security features. There is another EFF article which lists some security features:
- end-to-end encryption (many messaging apps use or are based on the Signal protocol)
- code quality (using “secure” algorithms doesn’t mean that they are securely implemented)
- user experience (can users easily send and receive encrypted messages?)
- service availability
- encrypted cloud backups (some messengers store unencrypted backups on the internet rendering E2EE useless)
- secure auto-updating mechanisms
- messenger of sufficiently high popularity that its use is not suspicious
- indicators of compromise that are recognizable to an end-user
- verification of identities
- aliases instead of phone numbers
- avoidance of network metadata
- contact discovery without disclosing your contacts to the service provider
- reproducible builds
- binary transparency
- the same level of security even in group chats
No need to say that no messenger offers all of these features. You have to be aware of these features and find the messenger which fits your needs.
If you look for “secure” e-mail, you will mostly find GnuPG- or OpenPGP-based solutions. GnuPG and OpenPGP are around for years but lack usability. Some services try to make them more usable by implemented encryption directly in the web browser but they force you and others to use their services in order to benefit from encryption.
Similar to “secure” messaging, most people seem to consider “encrypted” e-mails to be secure and we face similar problems again:
- end-to-end encryption using GnuPG/OpenPGP isn’t widespread
- GnuPG/OpenPG aren’t easy to use
- metadata and personal data stored on servers remain unencrypted
Considering the fact that messaging apps are far more popular when it comes to private communication nowadays, we don’t discuss this here. However, we are absolutely convinced that the term “secure e-mail” is more than vague.
When it comes to “security” in the web browser, everybody seems to focus on HTTPS/TLS nowadays. However, there are some issues since a web server can:
- provide self-signed or distrusted certificates
- offer insecure TLS protocol versions (1.0, 1.1) or even really old SSL
- enable cipher suites with weak cryptographic algorithms and without PFS or AEAD
- offer HTTPS without enforcing it (by enabling HTTP and HTTPS)
- embed insecure third-party content
- provide revoked or illegally issued certificates
- enable only weak elliptic curves and DH parameters
- provide useless Content Security Policies and other security-related HTTP headers
- be vulnerable to common attacks due to outdated web server software
Needless to say that there are many more security features than just HTTPS. Furthermore, HTTPS can be rendered useless if configured wishy-washy. And that isn’t all, because you must consider that not only the server must be configured securely but also your client. The list above doesn’t include all available web security features and some modern security features aren’t widely supported by non-mainstream web browsers.
All in all, “secure” browsing is far more than only enabling HTTPS and hoping for the best.
If we take some points mentioned above into account, “security” …
- … changes over time
- … isn’t clearly defined in most cases
- … heavily depends on the capabilities of an attacker
- … is a process and not a property
- … requires a holistic view and not detached assessments of separate security features
- … isn’t “one size fits all”
Keep this in mind when you discuss “secure somethings” in future.