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.


Understanding more about hashing

Written on 11 February 2015, 11:21pm

Tagged with: , ,

Brute force vs dictionary attack vs rainbow tables

Brute force: least efficient, tries all the possible values.
Dictionary attack: tries a predefined list of values
Rainbow tables: contain pre-computed hashed values. If a single salt per db is used, then the pre-computed hashed values have to be updated (to include the salt). If a single salt per password is used, then the pre-computed hashed values have to be updated for each password.
More here.
Note: rainbow table can only be used if the hashed values are available.

Hashing properties

1. Collision resistance: it should not be realistically possible to find two messages giving the same hash
2. Pre-image resistance: given the hash, it should not be realistically possible to obtain the message (we ask an adversary, given only H(m), to find m or some m′ such that H(m′) = H(m) )
3. Second pre-image resistance: given both the hash and the message, it should not be realistically possible to obtain another message with the same hash.
More here and here

Remember:
Hashing is not compression (you can’t go back to the original string)
Hashing is not encryption (for encryption you need a key)

What are you hashing

– not sensible data: use MD5/SHA family of hashing functions
– sensible data (like passwords): PBKDF2 (*), bcrypt or scrypt

Key derivation

This is about transforming a password into a key that can be used for encryption. Think about encrypting a file with a password.

The output of a password hashing function is acceptable as a symmetric key, after possible truncation to the required size.
link
LastPass utilizes the PBKDF2 function implemented with SHA-256 to turn your master password into your encryption key.
LastPass user manual

(*) PBKDF2 is in fact a Key derivation function, not a hashing function.