Passwords - 64 Characters, Changed Daily?

isepic writes "It seems over the past few years that the password requirements have changed - each time making it even more difficult to crack. My company just changed its password requirements from 180 days down to 90 for most servers and from a minimum of six characters up to eight. So, as parallel processing computer clusters gain in power according to Moore's law, how are we expected to change them in the next 2-10 years --- and how often?"

"Hopefully by then, there will be a better way, but I really don't want to have to change my password every 8 hours, and not be able to use the last 5 I've used, AND have them each be some awfully long and complex string of hard-to-remember ASCII codes just because a computer can crack a 32 char password in 10 seconds.

What are your thoughts? Do you think one day we'll be SOL, or do you think something 'better' may come (e.g. biometric scanners on every keyboard and or mouse and or monitor - etc.)"

Comments

Re:One time pad

[rfc1394]

They have this out already, check out S/Key. Since the password is never reused, and is never sent over the network in the clear, it's theoretically uncrackable by software methods. Would require social engineering, which raises the cost and hassle to try and steal.

Re:Use the Bible

[rfc1394]

I think the answer is probably to go with some sort of one-time pad system like S/Key, combined with some permissions based service, perhaps something like Kerberos. Kerberized S/Key might be an interesting concept...

Re:Bad assumption

[rfc1394]

Brute force, however, will always work, no matter what algorithm you use. The only way to make a more secure password, is to use a better password, a better hash algo won't help a damn.

Let's consider a system that remembers how many times I have logged on. When I want to log on again, I submit my password combined with the login number. I am in effect submitting two passwords; the hash of the actual password and the hash combined with the current login number. And I'm submitting a hash, not the actual password over the wire. The system keeps the hash of the password and that hash combined with the number that is itself hashed, and that's all that's transmitted. You get the password file and brute-force crack the passwords. Your attempt to break my account doesn't work because it lacks the additional identifier. You don't know which identifier it is because you need to know which login number I have made.

Now think your brute-force system works every time?

Now all I need to do is send two MD5 values; the original password and the hash plus the login number, itself hashed. The first verifies that it's the correct password, the second verifies it's the correct use. The login system only needs to verify the second identifier is a match, it never needs to store it. All you'll ever have is the first half of the solution, because it will always change. No amount of brute force can break a one-time pad especially where the pad isn't stored. All that is stored is the login number, presuming you can figure out where it is. And if you don't know whether the login number goes first, or goes after the password, you're likely to get caught long before you can gain access.

Or even easier, when I log on, my system sends me the time and date, I (on my computer that connects to it) send back the hash of my password, plus send that hash concatenated with the date and time it sends me, MD5-encrypt, and send that hash back to it. It knows when it sent me the time and date, so it splits it into two pieces, checks the first to make sure it's a valid hash of my password, then takes that and concatenates it with the date and time it sent me and checks it against the second hash.

Also, since you don't know that what I'm sending is actually, in effect, two passwords, you're trying to break a 256-bit cypher instead of trying to break two 128-bit ones; I'm not sure but it might mean you're looking in the wrong place and will never get the correct answer.

This does four things: (1) The attacker would also have to tap the transmission between me and the host computer; (2) they would have to know the context of the transmission since they wouldn't know that the hash was actually two hashes; (3) even if they crack the hash, all they get is a password that isn't even useful any more because it was a one-time pad; and (4) it prevents use of man-in-the-middle replay attacks since the identifier, either the time of day or the login number would be wrong.

I think S/Key did something like this, but went even further because it used a series of words to encapsulate the numbers, so you not only needed to know the password, you had to know which access number it was, and you had to know what word translates to which number.

I think maybe I'll write this up, it sounds like it might just be a really good idea.

Paul Robinson <Postmaster@paul.washington.dc.us>