AutoZone passwords

[Shaun]

I think we have some AZ folks on the list... I'm curious as to the
rationale behind autozone.com account passwords being capped at a
maximum of 10 characters. Any input?

Shaun

[Kevin Ponds]

Hello,

Ten characters is simply the maximum size that the database schema supports.

Against an online attack (2000 requests per second which is more than is realistically possible given rate limiting controls, in reality we would immediately respond to an attack at 1/20th this speed), this is more than enough complexity, it would take 135,000,000 years to exhaust the search space of a 10 character alphanumeric password with mixed case (no special characters).

Against an offline attack (if a hash table were compromised and the attacker could directly compare hashes), the feasible amount of requests per second depends on both the hardware available and the efficiency hashing algorithm.  md5 is a well-known baseline and it is possible for an attacker with modest hardware to compute 100 billion md5 hashes per second, which would allow him to crack 10 character alphanumeric mixed case passwords in ten weeks if they were encrypted with md5.  However, md5 is a poor choice in the modern era as much more complex and inefficient algorithms exist.  My personal favorite and recommendation (I cannot disclose the internals of our ecommerce application for obvious reasons, but I recommend the same password hashing algorithm to everyone who can use it) is the bcrypt algorithm with 10 iterations which requires 100x the time to crack as md5.  The main draw of the bcrypt algorithm is that inefficiency can be increased on the fly, so if five years down the road from now, you want to make your passwords harder to crack, you can do so easily.

Rainbow tables (precomputed tables of all possible hashes) are the flavor du jour these days, but I am not aware of any publiclly available rainbow tables for 10 character mixed case alphanumeric.  If one were available, the size would be 8TB.

Today, I don't believe our password field size to be a major security risk, but we are very interested in increasing it, simply because some users demand it, especially users using tools to autogenerate their passwords or using password managers such as LastPass (which I recommend) and who are used to having longer passwords.  I think the user experience issue is very important here.

Please feel free to direct mail me if you have any further questions.

Thanks,

Kevin Ponds

Shaun

--
You received this message because you are subscribed to the Google Groups "GOLUM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golum-group+unsubscribe@googlegroups.com.
To post to this group, send email to golum...@googlegroups.com.
Visit this group at https://groups.google.com/group/golum-group.
For more options, visit https://groups.google.com/d/optout.

[Aaron, M]

Why is the password being stored directly in the database... 

[Douglas Sims]

I had the same thought when I read Shaun's message.  Capping the length of the password at something like 10 characters implies that the actual password, not the hash, is being stored in the schema.  Cryptographic hash functions produce hashes of the same length regardless of the length of the original input.

Of course, a more practical explanation is that they probably do, in fact, do the right thing and store only the hash and salt, but that the ten-character limit is an artifact of an older implementation that did store plaintext passwords and has been replaced, but the web forms haven't been updated.

mysql> select sha2('short', 256);
+------------------------------------------------------------------+
| sha2('short', 256)                                               |
+------------------------------------------------------------------+
| f9b0078b5df596d2ea19010c001bbd009e651de2c57e8fb7e355f31eb9d3f739 |
+------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> select sha2('really really long password that has a lot of characters concatenated with a salt that is unique for each password and stored in a separate field', 256);
+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| sha2('really really long password that has a lot of characters concatenated with a salt that is unique for each password and stored in a separate field', 256) |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 86377c7bc77c29e943461d47fb4d049cce98722c9916a53ff87e55abde767d2b                                                                                               |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

On Sat, Aug 6, 2016 at 8:11 AM, Kevin Ponds <kevin...@gmail.com> wrote:

[Kevin Ponds]

I'm sorry I misspoke there.  It is the maximum length that the method to accept the password supports

[Kevin Ponds]

Yes, it's a commercial ecommerce framework and the configuration of the web forms and input validation is decoupled from the data storage implementation.

Sorry for not being clear earlier.

[Douglas Sims]

Another Memphis IT WTF question... why is it, even after a redesign, that the FedEx home page still asks me to choose my country at every visit.  Is Rob Carter on this list?

https://twitter.com/thurrott/status/761248887109713921

[erik]

Penetration tester here, there is another reason as to why this is bad practice. You need to think about the user base itself. 

We stress to users to incorporate pass phrases instead of passwords. A pass phrase is more secure due to length, and the fact that it's absolutely not a dictionary word. 

Limiting a password to 10 characters eliminates the pass phrase option, so users are inclined to use a dictionary word, probably combined with a number to keep it easy to remember. 

So now, instead of the secure pass phrase of "ThisIsMyAutozonePassword2016!!" A user might use "Autozone16" which is most likely going to be in any rainbow table that is targeting Autozone. 

Password limits simply reduce entropy, and increase the chances of a dictionary attack success. Although some users may have a non-dictionary word as their password, with a 10 character limit, it is a safe assumption that the majority do have one, and that not all 10 characters are being used by every user. 

This has eliminated a large portion of any rainbow table, which greatly reduces the time frame of a successful attack. 

Just my .02 cents. 

 

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to golum-group...@googlegroups.com.

[Robinson Mitchell]

Storage method isn't listed here.  Best practices would dictate storing a salted SHA-256 hash of the password which would store as a 64 character field whether the password itself is 1 character or 100, so there must be another reason - my first guess would be it's an arbitrary limit imposed by an  old-school programmer, but hey, there's a lot of sloppy code in commercial packages sold under the "price it high enough, some idiot will buy it" business model.

Rob

[Chris Mohler]

In the interest of keeping this thread going: https://xkcd.com/1700/

Of particular interest on this one is the alt/title text on hover ;)

Sorry to butt in - I mainly lurk here, but I find crypto quite interesting. I've enjoyed the thread thus far, was kinda hoping for a few more responses. 

At the risk of making a nuisance of myself, I'll post one more XKCD link, one that invades my brain whenever I create a new PW:

https://xkcd.com/936/

Happy Correct Horse Battery Staples everyone,

Chris

[Joseph Giacone]

Haha, those are great!  Haven't seen the password one in a good while!

--

[Douglas Sims]

If anyone hasn't already seen this on Hacker News, r/programming, etc., here's a nice summary of the new NIST password standards:

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

and the original source: https://pages.nist.gov/800-63-3/

Reading this made me realize that the password policies on a few projects I've been responsible for recently are not quite up to these standards (arguably not too far from them, but we can do better.)

- minimum length 8 characters, maximum at least 64

- no security questions for password recovery

- no composition rules (e.g., at least one upper case, lower case, number...)

- no automatic password expiration

- check new passwords against a known-bad list

- salt, hash, and stretch