5 ms·

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 consider

• twblalock 10y ago
  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.
• ramimac 10y ago
  In the past I've used https://pythonhosted.org/Flask-Security/ https://pythonhosted.org/Flask-Security/ for Python Flask password management (with bcrypt) and it fit my use case.
• mmaunder 10y ago
  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 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.
  • tpro 10y ago
    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.
    • ximeng 10y ago
      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.
      • mmaunder 10y ago
        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 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.
    • yeukhon 10y ago
      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.