4

[S]ome passwords are gleaned by hacking into computers where intruders can find stored passwords. Those are stored in encrypted form, but there's software that can attack the encryption. Nearly all encrypted passwords are stored with the last character in clear text, warns NASA, so the last character is a throwaway. [Emphasis added.]

See #5 in Tech News Daily: How to Write the Perfect Password - Jan. 27, 2010

Does anyone know whether / when this is true? Have a reference suitable for an intelligent non-mathlete?

I usually assume "encrypted" actually means some salted iterated unidirectional hash but other forms of encryption are possible.

BillR
  • 219
  • 1
  • 8
  • 13
    Nearly all outlandish claims are bogus. – John Deters Mar 26 '14 at 01:14
  • 3
    The article cites NASA, but does not provide a reference. From the language of the citations, one wonders if the 'last character in plain text' issue is internal to NASA and not a general weakness in encryption schemes... – schroeder Mar 26 '14 at 14:23
  • 5
    Also, the National Aeronautics and Space Administration isn't really an authority when it comes to IT security. – Philipp Mar 26 '14 at 15:06
  • 1
    @schroeder The reference is a NASA web page that no longer exists. (The URL was a footnote in the Imperva report the article also references.) – Xander Mar 26 '14 at 17:51
  • @Xander - Please feel free to add any citations you unearth to bottom of OP or as a comment. (Also ^ for research.) – BillR Mar 27 '14 at 11:46
  • 2
    Jan 2009 crawl of NASA site referenced in Imperva paper. WayBackMachine also has 2010 and other older and newer ones. https://web.archive.org/web/20090114141027/http://www.hq.nasa.gov/office/ospp/securityguide/V1comput/Password.htm – BillR Mar 27 '14 at 12:20

4 Answers4

10

No, I don't think this is true. News coverage gets this wrong all of the time, probably because its not an easy topic for an outsider.

It all starts with the term encryption. If you are really encrypting a password, you are most probably doing something wrong. Passwords in the context we are talking about are used for authentication. There is absolutely no need to have them available in the clear. Currently the best practice is to iteratively hash a password with a user specific salt. This process is practically irreversible and I don't see any way why a single character would be more prone to be reversed than any other.

However, if you don't follow this approach and doing something nasty like storing passwords in the clear or only storing them encrypted, it might very well be that passwords can be accessed in the clear. I don't see a way why the last character is more vulnerable than others, though, so I would strongly argue that the statement mentioned in your question is simply not true and someone was talking about something he has not understanding of, or at least oversimplified matters in such a way that they are simply false.

Karol Babioch
  • 1,247
  • 8
  • 10
  • Not to be a nitpicker, but you say "practically irreversible", but isn't it just mathematically irreversible? Or maybe that's the wrong word too, but I feel like "practically" is not strong enough. – Gray Mar 26 '14 at 18:22
  • 1
    @Gray No, I think "practically irreversible" is quite a good description. You can always try every possible combination (= brute force) and check whether it matches the given hash. So in theory it would be possible to get the initial password (or at least a matching one), but in practice this isn't feasible (life of the universe, atoms within the universe, etc. pp). – Karol Babioch Mar 26 '14 at 18:49
  • I see what you are saying, but I guess I'd argue that that isn't reversing it, just searching for a collision. Regardless, I found [This question](http://security.stackexchange.com/questions/11717/why-are-hash-functions-one-way-if-i-know-the-algorithm-why-cant-i-calculate-t) which is related and pretty much clears up my confusion. Thanks! – Gray Mar 26 '14 at 19:00
  • @Gray Well, we could argue all day and night about whether or not this should be called "reversing", but the fact of the matter is that in most cases it will be the original password itself not some random collission. Furthermore there are schemes which are absolutely not reversible - even with brute force attacks, e.g. the One-Time pad, so I would argue that for all practical matters we should call it "reversing" the hash. – Karol Babioch Mar 26 '14 at 19:02
3

I have seen sites that allows long passwords, but only uses the first X characthers, then create a hash with a salt from those X characters... leaving the last Y characters not used, and efectively could be anything.

for example your passwor would be 

mylongandboringpassword

with the X set to 8 the actually stored password (and all you would need to open are)

mylongan

so this below password would also be valid

mylongandfunpassword

not saying this is good practice, but I have seen it.

Sverre
  • 151
  • 3
2

This claim is nonsensical.

The most common practice by far is to take an MD5 hash (or, increasingly, something else like a SHA hash), with a salt. The salt is a random string added to the plaintext password before it is hashed, and stored with the lot; it serves to make it hard to compute tables of all possible hashed passwords since this must then be done for each salt value.

Sometimes it is necessary to have the plaintext password, for some challenge-response algorithms. In this case the password may be unencrypted or it might be reversibly encrypted (using AES, DES, or something).

In both cases, the password is treated as a blob; the output of the algorithm is the only thing stored. I suggest, if you are interested, you hash a file; you may notice that the last character of the hash and the last character of the file are usually different.

Another way to use passwords for authentication is to use Kerberos, which involves using the password to generate a keypair; in this case the server only needs the public part of that keypair, and requires none of the characters of the password at all.

I can't think of a single widely-used password storage mechanism besides cleartext that stores a single character of the password in the clear.

Falcon Momot
  • 1,248
  • 7
  • 17
2

There some things in that linked article that are true and useful. But identifying those parts from the things that are erroneous and misleading is something that can only be done by someone who doesn't need the advice in the first place.

As @user1201232 correctly pointed out, there are some (ancient) systems that only use the first eight bytes of a password. There are some more current ones (Windows Live/Hotmail) which truncate to 16 bytes. But I've never found anything that matches the particular claim you are asking about.

I suspect that the author is confused about unencrypted salt. Old Unix crypt() systems used two bytes of salt that were prepended to the password hash. So when you look at a record from an old style /etc/password file (we are talking about the days before shadow), the first two letters were not "encrypted".

Again, I can only speculate on what might underlie that particular claim. Most of the other errors in the document are common enough. E.g., I'm guessing that "NASA" instead of "NSA" is a spell checker thing.

Community
  • 1
Jeffrey Goldberg
  • 6,420
  • 17
  • 21
  • 1
    *I'm guessing that "NASA" instead of "NSA" is a spell checker thing.* -- No, the Imperva whitepaper that's also referenced does indeed quote password advice sourced from a NASA webpage, which incidentally no longer exists. The Imperva report doesn't mention the recommendation in question, so I don't know if it was, or was not something that was actually on that webpage at the time this article was written. – Xander Mar 26 '14 at 17:49
  • You are implying that newer systems encrypt the salt. I can't speak for non-Linux systems, but on Linux the crypt function still gets used with a plain text salt, it just is a longer salt with the newer hashing algorithms like MD5 and SHA-256. See the crypt(3) man page. If the salt were encrypted then authentication wouldn't work without the system storing the decryption key for the salt someplace on the system, which would be pointless IMHO. The point of the shadow file was to allow /etc/password to still be world readable, but the hashed string to be root only. – deltaray Mar 27 '14 at 14:19
  • I never meant to suggest that newer system encrypt the salt. Salt was (and is) unencrypted, but I was speculating about where two unencrypted bytes might be that is the source of the confusion. – Jeffrey Goldberg Apr 24 '14 at 01:12