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

Use a CueCat

[Safety Cap]

, as each one has a unique serial number encoded into its output. When you're ready to log in, plug in your :Cat, and use it to scan that barcode that only you know is the right one.

Even if some one steals your :Cat, they can't get in, and if someone steals your copy of "Learning the VI Editor" that you've used for the barcode without stealing your :Cat, again they can't get in.

Pointless

[jolyonr]

The harder a password is to remember, and the more frequently it is changed, the more likely people are going to forget it, and resort to insecure tricks such as writing it on a post-it note stuck to their monitor.

I can't see any good reason to change passwords frequently, other than to limit the damage done from a succesful intrusion. And then, is one month any worse than three months? All your data is 0wned regardless.

Exponential growth problem

[Kufat]

Every time you add another character onto an alphanumeric, case-sensitive password, the total number of possibilities is multiplied by 62. CPU throughput takes a very long time to increase 62-fold. So going from 8 to 10 characters increases the passwordspace 3844 times, and that's assuming only uppercase, lowercase, and numbers.

There's nothing to worry about until quantum computers can handle problems like this AND are available by someone you don't want accessing your data.

Bad assumption

[Phexro]

You're assuming we won't have a better, harder-to-crack hashing mechanism by then.

This has been a process of incremental improvements - first crypt(), then shadow passwords, then MD5 hashes, and so on. We will certainly have something harder to crack in the future.

Re:Bad assumption

[grumbel]

Shadow passwords aren't a hashing mechanism, all they do is store the hashes in a file that the users can't read. Just Unix permissiosn, pretty trivial after all.

About crypt() vs MD5, I don't think that they make much different when it comes to cracking actual passwords, all MD5 does is allow you to use longer passwords, it doesn't enforce it by any means. If your password is in a dictonary, no matter what hashing algo you use, I can brute force it in a few seconds.

The only advantage a good hashing algorithm provides is that it ensures that you can't from a given hash calculate back the original password by other means than brute force. 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.

Re:Simple...

[XaXXon]

Oops, except that's often now how the password is cracked. You don't try the password on the machine over and over, you get a hold of the encrypted password and check against that. This is much faster, as it involves no network activity for each try, only getting a hold of the encrypted password information.

The solution to the problem you are trying to solve is already in place on most systems, anyhow. When you fail to provide the correct password, you are punished by having to wait some amount of time (usually seems to be about 3 seconds). This way, instead of being able to test millions of combinations a minute, you can try 20. This way, your "friend" can't lock you out by typing your password wrong 3 times. Practical jokes are commonplace where I work.. don't need to make it easier on 'em..

Re:Just do what I do

[Abcd1234]

This should be modded insightful. These kind of forced password-change policies do one thing only: encourage people to choose easy-to-remember (and hence, likely easy-to-crack) passwords. Even worse, it encourages people to write their passwords down and store them in what is probably a very insecure location! So, in the end, you get only a marginal increase in security.

Frankly, I think the best bet is to encourage users to just select longish (>8 characters), complex password (no word substrings, more than just alphabetic characters, etc), but don't force them to change it. After all, brute-forcing a complex, 8-character password is still a fairly difficult process.

Re:Biometrics

[Blastrogath]

If you use biometric data for your passwords then you can never change your passwords. The first time you use a cracked login terminal you've lost security forever, unless you have surgery.

Re:Simple...

[gl4ss]

it's restricted on most/all systems already that way and besides the throughput limitations on bruteforcing a live system would prove quite troublesome.

generally you would sniff the datastream and try to crack that I imagine(because that's the only thing you could do).

(insecure software with flaws proves the biggest security problem for the foreseeable future anyways, there's always possibility of using single use passwords which are _already_ in use on sensitive/important systems)

Hmm

[Erwos]

I was reading a textbook about this very issue just a couple days ago at work (I was bored, and there it was in lost and found pile). Don't recall the name, but it was basically about biometrics for security purposes.

The book stated near the very beginning that, basically, passwords are useless because the really secure ones are hard to remember, and that little problem causes people to do other things that mostly destroy the security of a "secure" password anyways (such as the infamous post-it note on the monitor).

The book's solution was fairly common-sense: implement different layers of security. That is to say, a password on its own is bad, but a token+password (say, USB memory stick with accesss code) can actually be a lot better.

The best stated was "bio+token+password". Seems reasonable to me, at least.

-Erwos

Yeah right...

[imsabbel]

Biometrix is just like passwords, just you cant change your fingerprint/iris scan/voice pattern after someone has exploided/stolen/copied yours.
Great.

MOD THIS GUY UP!

[theLOUDroom]

This raises another good point, where if you're properly controlling the methods to access whatever it is you're protecting, you can cut off someone that's trying to brute force (ie, wrong password 3 times in a row). Then your length isn't going to matter as much.

That's the key here folks.

Passwords should only be used in circumstances where you can control the number of attempts.

If you CANNOT cut off access after N failed attempts, you should be using a full-fledged lots-of-bits crypto key. An example would be using PGP on an email.

A lot of people are looking at the situation in terms of Moore's law. Moore's law should have no effect on how many logins per minute you allow me to attempt. That is a config option.

In sort, it doesn't matter how fast your computer is. If ebay only lets you try 3 logins per minute, that's all you get.
If you're letting people try 1,000+ password per minute on your system, THAT's the problem, not that some guy only had a 6 character random password as opposed to 8.

So to sum up:
Passwords should not be used in case where somebody else is going to have >100 attempts to break it. At that point you should be using >1KB crypto keys.
This is not a password policy problem, it's human somewhere not understanding what passwords are good for.

Re:Yes and No...Better solution:Assign the passwor

[slash.dt]

There is a MUCH better way to do this. First off, instead of letting users choose their own passwords, assign them for each person. This lets you, the administrator to be entirely in control of all passwords on the system. With this control, you can maintain a master list of all users and passwords securely in either encrypted/secure files (with no permissions to anyone but root). This also allows you to force good passwords onto users. They do not need to be impossible, but something like 2 three letter words or partial words (chosen at random) with 2 other ASCII characters are usually not too hard for people to remember, but are still tough enough to make it hard to guess with password word lists.

There is so many things wrong with this that it is hard to know where to start. I'll just chose a couple.

First, forcing passwords on users is dumb. What might be an easy combination of words and number s for you to remember might be completely impossible for me to remember if the word means nothing to me. And if I can't remember I am going to write it down. It is much better to allow people to chose their own passwords to that they can make a combination that they can remember.

Second, accountability for your password goes out the window when someone else knows and controls the password. If the adminstrator knows all the passwords, they can logon as the user without the user knowing. Alternatively, the user can suggest that the administrator did the action which the user is being accused of.

More intelligent password checking rules is a much simpler and more effective solution.

Re:Just do what I do

[arminw]

Some systems do not allow any more tries at logging in after a few unsuccessful attempts. After an hour or so, the systems resets and gives the user another chance to try to get in. If that also fails, the user must call the system admin. This process goes a long way toward thwarting multiple access atempts.

None of this helps of course if the user's system is breached and some sort of keyboard sniffer is active.

Re:Just do what I do

[robosmurf]

The problem with a strict lock-out policy is that it leaves you vulnerable to a denial-of-service attack. All an attacker needs to do is guess your password a few times to cause a lot of trouble.