in

This Blog

Syndication

Tags

News

AlertBoot offers a cloud-based full disk encryption and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.

Archives

AlertBoot Endpoint Security

AlertBoot offers a cloud-based full disk encryption and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.

Data Security: Old Amazon.com's Passwords Valid Up To 8th Character

The weakest link to modern, strong encryption lies in its users.  More specifically, it lies in the fact that users don't protect their passwords as well as they could: they write it down on a post-it, share it with co-workers, or even give it over the phone, in what could a social engineering scam.

Once in a while, though, you run into problems where the weakest link lies in the program itself.  Amazon.com, for example, truncated passwords after the eighth character, rendering passwords that much weaker.

Affects Old Passwords Only, Truncated and Capitalized

The story broke open on Reddit when a reditter noticed how he could log into amazon.com with the wrong password.  A discussion quickly followed.  What people (including those who don't frequent reditt.com) think might be happening:

Amazon.com used (past tense) unix's crypt() function to encrypt older passwords.  Unfortunately, crypt() truncates everything to eight characters, meaning anything after the eighth character gets removed.  For example, if your password is 123456789, the 9 is thrown out and 12345678 is kept as the password.

There is also speculation, based on testing, that amazon.com also converted all passwords to uppercase before storing them as passwords.  As we'll see shortly, both contribute towards weaker passwords.

That's the bad news.  The good news is that amazon.com doesn't do it anymore.  In fact, this issue seems to affect passwords that are pretty old, to the tune of two or three years (or older).  So, if you haven't changed your password at the on-line bookstore, now's the time to do so.  You can even enter your old password as your "new" password.  Despite being the same password, you'll actually be better protected.

Password Strength Lies in Diversity, Length

The strength of a password lies in its length: comparing two passwords, 11 and 111111111111111111111, most people will (correctly) say that the latter is a stronger password.  Overall, though, both passwords are weak since they're composed of one character only.

If we were to take 111111111111111111111 and compare it to 12345678934567891201, both composed of 21 characters, we'd say the latter is the stronger password.  So, it's not just a matter of length, it's also a matter of diversity: the more diverse the characters making up the password, the more secure it is.

Combine length and diversity and you can say, the more complex your password, the more secure it is.  Do anything to counter to this claim, and you're weakening your password pool.  Let's look at amazon.com's past practice.

To begin with, they truncated passwords to 8 places.  If I recollect correctly, they also had a minimum password length, so there was an upper and lower limit to what a password's length could be.  This limits the number of passwords you've got to brute-force before finding the correct one.

To be fair, though, it probably wouldn't matter much.  The difference between going through all 8-character passwords vs. all passwords beginning from 1-character passwords to 8-characters passwords, inclusive, borders around 4% if only using the 26 characters in the alphabet.  If you include numbers, or differentiate between lowercase and uppercase letters, the difference becomes less than 1%.  The reason?  Because the total number of passwords one can create grows exponentially with the password length, the number of passwords composed of 8 characters quickly outnumbers those of 7 characters or shorter.  You can read more about it here, under the section "Do Encryption Solutions Work Anymore?  Hacking Passwords."

Long story short, the lower limit is not as much of a problem as the ceiling on password lengths.

Perhaps even more problematic is converting all passwords to uppercase.  There are 26 letters in the alphabet (the English one).  Differentiating between upper and lower case means a total of 52 letters.  The difference in exponential growth between 26 characters and 52 characters is tremendous:

PWL 26 characters 32 characters 52 characters
1 26 32 52
2 676 1024 2704
3 17576 32768 140608
4 456976 1048576 7311616
5 11881376 33554432 380204032
6 308915776 1073741824 19770609664
7 8031810176 34359738368 1.02807E+12
8 2.08827E+11 1.09951E+12 5.34597E+13
9 5.4295E+12 3.51844E+13 2.77991E+15
10 1.41167E+14 1.1259E+15 1.44555E+17

If the length of the password (PWL) is one, you can have either 26 (a, b, c, etc) or 52 passwords (A, a, B, b, etc.), respectively.  When the length of the password increases to two places you can have either 676 (a, b, c...aa, ab, ac...ba, bb, bc...etc.) passwords or 2,704 passwords.

By the time you reach a password that is 5 characters in length, the difference is 11.8 million passwords vs. 380 million passwords.  Exponential growth is a powerful thing.  Even if you were to use a password that combines 26 characters and 10 numbers, it wouldn't come close to the complexity offered by 52 characters with no numbers. (And, obviously, passwords that involve upper and lower case numbers as well as numbers would offer more passwords.)

Amazon.com's past password policies (or should I call them practices) shortchanged their users, since the "promised" security of the password turned out to be less than what as actually offered.

Why Didn't Amazon Do Something About It?

Of course, many might wonder, "well, if Amazon knew of the problem, and thought it may be problematic enough that they changed how they handled passwords three years ago, why didn't they go all the way?  Why not ensure that the correct passwords were used going forward?"  Absent an official communication from the on-line retailer, we can only speculate.

Storefrontbacktalk.com, however, has an excellent analysis of the possible whys.  Basically, it all revolves around the fact that amazon.com never had the actual passwords -- they had truncated versions, at best -- so they couldn't "fix it" internally.  People dislike being forced to randomly change or update passwords, so that was a dead end.  It would have been bad PR to admit to the problem, so they couldn't announce it (plus, imagine the field day hackers would have with that announcement).

It looks like Amazon may have just let time do its job: at some point, people would reset their passwords, and the security issue would resolve itself.


Related Articles and Sites:
http://www.wired.com/threatlevel/2011/01/amazon-password-problem/
http://www.pcmag.comz/article2/0,2817,2378777,00.asp

 
<Previous Next>

Biometric Security: China Develops Technology To ID A Person Via His Gait

Data Encryption Software: Man Snatches Laptop From Starbucks Customer

Comments

No Comments

About sang_lee

Sang Lee is a Senior Account Manager and Security Analyst with AlertBoot, Inc., the leading provider of managed endpoint security services, based in Las Vegas, NV. Mr. Lee helps with the deployment and ongoing support of the AlertBoot disk encryption managed service. Prior to working at AlertBoot, Mr. Lee served in the South Korean Navy. He holds both a B.S. and an M.S. from Tufts University in Medford, Massachusetts, U.S.A.