DEV Community

Cover image for Handling Passwords
dewbiez
dewbiez

Posted on • Updated on

Handling Passwords

Rules

  • Minimum length of either 8 or 16 characters.
  • A maximum length of 2,048 characters.
  • Check if password is in breaches? (optional)

It's probably a good idea to make sure they're not putting in a common or breached password. I don't have any other rules, it's pretty simple. I think having the one or more numbers, symbols, capital letters, is a bit overrated. I don't really need it, do I? Got any examples/scenarios on why an application would need or should have something like that? Please, share.

And I encourage people who are writing password this.

Storage

And as for storing passwords, I'm not just gonna leave it as plain-text, unless of course my intent is to steal credentials. So I'd use a strong hashing algorithm like Bcrypt or some variation of Argon2. Hashing the passwords is good enough, or so some of us believe. While I don't doubt that hashing the password is good, I believe that it could be taken further to protecting the passwords.

Yes, encrypt the hash, with something strong. Preferably AES-256 or AES-128. And perhaps a more complex approach signing keys with RSA and encrypting with AES based on that. Not gonna get too far into it(I don't wanna start talking about stuff I don't understand).

Doing it this way gives hackers/crackers whatever you wish to call them, another step. To decrypt the hash, then finally deal with the hash.

Summary

Make sure the password is within (8 or 16)-2,048 characters threshold, optionally check if it's common or breached. Hash the password, then encrypt the hashed password, and finally store it somewhere.

Recommendations

Check these out, while you're reading about passwords.

Top comments (12)

Collapse
 
antogarand profile image
Antony Garand

Yes, encrypt the hash, with something strong. Preferably AES-256 or AES-128. And perhaps a more complex approach signing keys with RSA and encrypting with AES based on that. Not gonna get too far into it(I don't wanna start talking about stuff I don't understand).

Why would you do this?
Bcrypt and Argon2 are already great hashing functions, encrypting the hashes will provide no benefits while hurting performance.

Collapse
 
devmazee2057282 profile image
dewbiez

Because, I'm just like that. And I've read elsewhere that it isn't bad to do something like that. From a valuable source regarding security.

And that's the thing, most developers don't take the extra step. I do. And you might say it brings down the performance, and yes it does. But not by much if you're doing it right. And I've run some tests, and it doesn't make that much of an impact on performance, especially since AES is pretty fast compared to some of the other encryption algorithms.

Collapse
 
antogarand profile image
Antony Garand

The important part of hashing passwords is for them not to be reversible.
The extra step is salting those.

Encrypting them does not provide any security benefits, other than perhaps having two secret keys in different areas (salt in database, AES secret hardcoded in code), but makes everything else harder.

Thread Thread
 
devmazee2057282 profile image
dewbiez • Edited

You're right, the password shouldn't be reversible. It's not, because it's hashed before it's encrypted. As said in the resource above, it's realistically not much securer than the hashing algorithm.

It just makes it a pain for anyone trying to steal user passwords. Meaning they have to decrypt it someway(exploiting the server and executing code to decrypt, being one way, or getting the encryption key), before they can even deal with the hashes.

I believe that a decent hashing algorithm with a salt and peppering, along with decent encryption provides the same security(if not better) over just plain decent hashing with a salt.

Collapse
 
devmazee2057282 profile image
dewbiez • Edited

Also, here is the source.

See, they do it. FYI, the people who made it are amazing.

And actually, yes it does have benefits, in my opinion.

Collapse
 
antogarand profile image
Antony Garand

From this source:

But realistically, this library is only about as a secure as bcrypt.

The downsides are not worth it IMO, but it still is a nice resource to have.

Thread Thread
 
devmazee2057282 profile image
dewbiez

Yeah it still is nice to have it.

Collapse
 
qm3ster profile image
Mihail Malo

Because this way, if they lift the whole password database at rest, they still need to decrypt it to even see the usernames or start trying breached/short passwords.

Collapse
 
tux0r profile image
tux0r

Linking the appropriate xkcd comic and still recommending a "password length" implies that you have not fully understood entropy. 2,048 "A" characters are not really better than "correct horse battery staple".

All of that should not matter in a safely written web application with 2FA, login attempt limitation and sanely salted databases though.

Collapse
 
devmazee2057282 profile image
dewbiez • Edited

I understand what you mean. I was just recommending some things. I have it set for 2,048 because some password managers have really long passwords. Again, 2,048 is a bit long for a password ... but if say a password manager supports that kind of length, it'd be nice for it to be supported.

And yes I know that 2FA and login attempt limitation would greatly improve the security.

Hey, thanks for the feedback. :D

Collapse
 
exadra37 profile image
Paulo Renato

Personally I would not allow less than 12 characters in a password, 8 is now easy to crack with enough computer cpu... just my 2 cents.

I really recommend to read some of or all articles on this series troyhunt.com/tag/passwords/

Collapse
 
devmazee2057282 profile image
dewbiez • Edited

I agree. Over time I had changed my view on passwords and gathered more information. I'll probably write a new post and close this one off.