Web PKI: 3 improvements

Written on 24 September 2017, 03:09pm

Tagged with: , ,

Some insights about web security from the excellent ‘Bulletproof SSL and TLS‘ book from Ivan Ristic.

– the Internet was not designed with security in mind
– the first efforts to improve this were in 1995, when SSL3 was released (by Netscape). Then TLS followed up.
– TLS 1.2 – the most recent version – was released in August 2008 (its successor – TLS 1.3 – is still under development, as of September 2017)
– the goal back in 1995 was to enable e-commerce. Today we have that (‘commercial security’), but we want much more.

One of the biggest problem with the Web PKI is the approach to certificate validation. The following improvements aim to fix that:
1. Public Key Pinning:
– addresses the fact that any CA can issue a certificate for any domain name without the owner’s permission.
– with pinning, site owners can select (pin) one or more CAs that they trust, creating their own (small) trust ecosystem
– delivered via HTTP headers (Public-Key-Pins)

2. HTTP Strict Transport Security (HSTS)
– allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
– also, when an invalid certificate is encountered, it instructs compliant browsers to replace warnings with errors, disallowing bypass.
– delivered also via HTTP headers (Strict-Transport-Security)

3. OCSP stapling
– There are two standards for certificate revocation (revocation is used when the private key is compromised or no longer needed)
– CRL (Certificate Revocation List) is a large list of revoked certificate serial numbers maintained by the CA. Because of the size, the lookup is slow
– OCSP (Online Certificate Status Protocol) allows browsers to obtain the revocation status of a single certificate.
– the problem with OCSP is that the individual lookup can slow down browsing and can affect the performance of the OCSP responder for high traffic websites
– to address this, OCSP stapling allows each server to embed an OCSP response directly into the TLS initial handshake

In the end, do not forget that the current Web PKI is controlled by 2 actors: Certificate Authorities (interested in profit) and browser vendors (interested in market share).

Neither group has strong security as its top priority, but they are not necessarily to blame—at least not entirely. They won’t give us security until we, the end users, start to demand it from them.

Update 10 October 2017: I have just enabled HSTS here. Inspired by Troy Hunt.

Flaws exposed by the WannaCry ransomware

Written on 19 May 2017, 11:37am

Tagged with: ,

Users

1. Using old OS (in some cases, pirated, so impossible to upgrade)
2. Not updating their OS (sometimes, manually disabling the Windows update)
3. Not using a proper anti virus / anti malware solution
4. Not taking regular backups

Administrators

1. Not minimising the attack surface area (keeping the SMB service enabled even if it’s not used)
2. Not taking regular backups
3. Lack of a proper IT Security strategy, including guidelines on how to respond to security incidents

NSA

1. Not disclosing the vulnerability until their exploit was stolen

Microsoft

1. Not having a seamless Windows update process (mixing critical security updates with minor ones, forced restarts, etc)

Some links:
https://www.troyhunt.com/dont-tell-people-to-turn-off-windows-update-just-dont/
http://www.nbcnews.com/storyline/hacking-of-america/companies-stockpiling-bitcoin-anticipation-ransomware-attacks-n761316

But in the end, things might work out just fine 🙂

A few things about passwords in 2017

Written on 17 April 2017, 02:40pm

Tagged with: ,

1. Admins: Forget about stupid password rules and focus on the length

The idea is to focus on the one understandable, simple, practical, works-in-real-life-in-every-situation rule: length. Users can enter (almost) anything, in proper Unicode, provided it’s long enough. That’s the one rule to bind them all that we need to teach users: length!
Jeff Atwood – https://blog.codinghorror.com/password-rules-are-bullshit/

And with this in mind, don’t impose a maximum password length!

2. Admins: Stop asking for periodic password reset *

This applies mostly to large organisations, who are asking the users to memorize a new password periodically.
This is not practical and what will usually happen is that the users will slightly alter the previous password. For instance, some users will increment a number at the end of their password (ex. the number of the year/month). So this measure is more likely to reduce the overall security rather than improve it.

Research suggests frequent mandatory expiration inconveniences and annoys users without as much security benefit as previously thought, and may even cause some users to behave less securely. Encouraging users to make the effort to create a strong password that they will be able to use for a long time may be a better approach for many organizations, especially when combined with slow hash functions, well-chosen salt, limiting login attempts, and password length and complexity requirements. And the best choice – particularly if your enterprise maintains sensitive data – may be to implement multi-factor authentication.
Federal Trade Commission – Time to rethink mandatory password changes

* There are, however, certain situations when a forced-password-change makes sense.

3. Admins: Allow pasting passwords

Just leave the password managers do their job.

Preventing the copying and pasting of passwords does nothing in terms of preventing brute force attacks. It also breaks usability in a number of key ways, not to mention breaking password managers. Essentially, it forces users to make up easy passwords so that they can type them without making mistakes. Thus allowing easy access via brute force attacks.
Philip Norton’s comment on The “Cobra Effect” that is disabling paste on password fields by Troy Hunt

4. Admins: implement multi-step verification, but avoid SMS

The idea with multi-factor authentication is to test someone’s identity based on something they know (like a password) and something they have (like their phone). The problem with using SMS is the fact that they are sent to the user device. And this means that they can be intercepted. It’s recommended to replace that with a system generating one-time passwords (OTP) on the user device:

Adding a layer of SMS-based verification to your login process is certainly better than relying on a password alone. But two-factor authentication using SMS text messages isn’t technically two-factor at all.
Better tools like Google Authenticator or an RSA token prove that possession, by generating a unique code that matches one generated on a web service’s server. It’s a test that, thanks to some clever crypto tricks, doesn’t involve any communication between the two computers. That’s far more effective than sending a text message with a one-time code to someone’s phone. It’s less convenient, though, which may be why it’s also less commonplace.
“SMS has turned that ‘something you have’ into ‘something they sent you,’. If that transaction is happening, it can be intercepted. And that means you’re potentially at some level of risk.”
Andy Greenberg, WIRED – So Hey You Should Stop Using Texts for Two-Factor Authentication

Now, for the users part, it’s true, it’s becoming a little difficult to keep up with things: Security is Becoming Too Hard for the Layperson. But here are 2 easy things you can do:

1. Use a password manager

They don’t have to be perfect, they have to be better than not using one.

Some say password managers are a bad idea because “there is no such thing as 100% security”. Of course there isn’t! But there doesn’t have to be to justify using a password manager, it just has to be better than not using one.
Troy Hunt: Password managers don’t have to be perfect, they just have to be better than not having one

2. Enable multi-step verification where it exists

Start small: your email and main social media account (ex. Google + Facebook). Then continue with the others.