Hacker News Reader

Comment by gjkood | Hacker News Reader

In the interest of making this a learning experience for myself and others, I would like to get any feedback on the following questions.

What would be considered as strong/good/secure password/authentication algorithms if one had to implement this today?

What would you recommend today as a good/secure authentication library that one can use with a micro framework like Python Flask (or others)? What about the authentication library in the batteries included Django framework?

What about recommended general authentication libraries for other web application frameworks such as Phoenix/Elixir, Node based, Go based, etc?

Here are some links from OWASP/Google that offers some details:

https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_...

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

https://docs.google.com/document/d/1R6c9NW6wtoEoT3CS4UVmthw1...

View on HN

What would be considered as strong/good/secure password/authentication algorithms if one had to implement this today?

Use salted bcrypt or another slow salted hashing algorithm. The goal is to make it expensive to crack. For reference, the GPU version of hashcat (cudahashcat or oclhashcat) is very popular, and look at these benchmarks to choose a hashing algorithm and to understand what to avoid like the plague:

https://gist.github.com/epixoip/c0b92196a33b902ec5f3

Clearly md5 is a no no and bcrypt and a few others are a huge improvement.

However, I feel compelled to add (and please don't flame me for this, just sharing reality) that even MD5 can actually be very hard to crack if your users use a long password (12 chars or above) and a large enough character set. In other words, using 12 char or more passwords with uppercase, lowercase, numbers and symbols is hard to crack even if they used a crappy algorithm like md5.

So the ideal combo is a strong hashing algo and enforcing complex long passwords.

Is it even necessary to actual enforce password complexity? Or is it enough that those characters theoretically could be in the password? The size of the password-space is the same.

Whoever is trying to find a password that hashes to the known hash will order the passwords they try in order to prioritise testing more frequently used passwords like aaaaaaaaaaaa rather than mj(8anZ0$uQ,! , so if you can encourage people to choose a less predictable password you increase the cost of discovering the password for an attacker.

Correct. They'll also start with dictionaries of a few hundred million passwords which they'll run through fairly quickly. Then they'll use mask attacks as @ximeng said in ascending order of length and complexity.

https://hashcat.net/wiki/doku.php?id=mask_attack

So it's critically important to enforce length because short passwords will be cracked quickly even with slower hashing algorithms.

Yes, absolutely, for uniquneness and protection of "brute force guessing". It would be hard to find two people using the following password: "2#1mf!fAk", but it is extremely easy to find two people with the password "123456". Essentially you want to avoid to have a password in a lookup table("rainbow table").

And no, when you make the complexity super hard. I really dislike every website has a different complexity rule. Also, be aware that passphrase is a form of password. Instead of choosing "j2%25a^a2" as your password, you can choose a phrase you construct "hacker news is really awesome right buddy" (assuming the website cap at a reasonable length - allowing a long long password is a DOS vulnerability by itself). The pitfall of password/passphrase is reusing common password/passphrase which goes back to the first point - YES.

The real bummer is reusing your password and passphrase for every website. I have several sets of passwords. One set for financial/sensitive website for example.

Enforce length. Every other notion of "complex" has a very poor return (in terms of memorability:crackability) compared to just throwing a couple more characters on the end. E.g. if we suppose your "uppercase, lowercase, numbers and symbols" makes 60 possible characters, a 12-character uppercase, lowercase, numbers and symbols has the same level of security as a 15-letter lowercase-only password.

I don't know much about prebuilt end-to-end authentication libraries, but I would use bcrypt for hashing passwords.

I've seen conflicting opinions about whether scrypt is better than bcrypt, but I haven't seen strong enough arguments to convince me to switch.

In the past I've used https://pythonhosted.org/Flask-Security/ for Python Flask password management (with bcrypt) and it fit my use case.

Reply on news.ycombinator.com