Slashdot Mirror
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.)"
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.
Yeah, right.
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.
Please read my Canon EOS tech blog at http://www.everyothershot.com
just because a computer can crack a 32 char password in 10 seconds
And will all software in the future not have any kind of delay to prevent this sort of attack? Even now, we have login/ssh services that delay a couple of seconds between failed attempts.
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.
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.
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..
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.
This is why you should use a bad-password delay on your system. It doesn't matter how many passwords some fast computer can try a second if the system enforces a 2-second delay after each attempt.
To smash a single atom, all mankind was intent / Now any day the atom may return the compliment
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.
"The price good men pay for indifference to public affairs is to be ruled by evil men." -Plato
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)
world was created 5 seconds before this post as it is.
The rules are very simple (and haven't really changed):
For strong cryptography you need at least 128 bits of 'random' key data. Considering the average 'random' ASCII string has about 3 bits of entropy per character, that brings us to about 42 characters per 'strong' password.
Of course, in practice, this is not feasible (which is exactly why cryptography is less secure in practice than on paper).
Many companies have a 8-char/numerals/symbols password policy, and require you to change your passwords regurlarly.
The more regular you change your password, the lower the risk of a security compromise. And the same thing goes for the length of the password: the more characters in it, the lower the chance of a brute-force attack recovering the clear-text version.
These numbers haven't really changed over the past years, since the exponential development of computing-power was already taken into account when 'measuring' crypto-security.
The real downfall for 'classic' cryptography will come when quantum-computers are able to analyse all key-permutations in parallel 'quantum'-time. But by that time, not even biometrics will solve this problem.
I think, that by changing your 8-char password regularly (say every three months), and keeping to the 'add some random capitals, numbers and symbols'-rule, you are gonna be as 'secure' as you are humanly possible going to get.
It doesn't really matter how fast computers get. If a system only allows you a few wrong password attempts and makes you wait between each attempt, a simple password would take years to get cracked. The audit logs should be sending off alarms before that anyways.
You can't compare what the user has to remember to an encrypted password hash. Of course, someone with root or administrator privs can grab the shadow/SAM file and perform offline hacking with a powerful computer and crack the password quickly. If this is a problem trusting the sysadmins, then the password encrypting would need to become stronger, not the original password.
However, password111 password222 password333 and such would work. I can't imagine that would be any harder for someone only slightly modifying their passwords.
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
Plausible conjecture should not be misrepresented as proof positive.
Biometrix is just like passwords, just you cant change your fingerprint/iris scan/voice pattern after someone has exploided/stolen/copied yours.
Great.
HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
Instead of forcing employees to change their passwords all the time, companies instead should implement procedures to only allow 2-3 attempts at your password before requiring the account to be unlocked by an administrator.
Stop brute forcing at the source.
0110100100100000011000010110110100100000011000100
It may be a difficult process, but if you don't change your passwords I've got all the time in the world to get them.
The key thing is to educate users and not to set the password change period too short. It's a balance between more secure passwords and incovienience. If it's too much of a hassle people will look for a way around it.
You probably also need a corprate policy on passwords so that it's their boss telling them to act this way, not just some "clueless geek from IT". You should also have some written rules in said policy about what's an acceptible password. You'd be wise to also try your best to get the users to understand why this is important, or at least to convince them it is important.
"The price good men pay for indifference to public affairs is to be ruled by evil men." -Plato
I used a security failure at my office last week to make exactly this point...
No, nobody broke into the place. It's just that at 8am in the morning (when everybody's supposed to have shown up for work) stood myself (at that time, too new to have been issued keys) the summer intern (who will be never issued keys) and the sales rep (who thought he had been issued keys to open both the building and suite doors, but turns out to have been handed two building keys instead)... it'd fourty-five minutes before the owner would show up and unlock the door so we could all get to work. Two other people who have keys are supposed to start at 8am as well, but they were both on assignment away from the office that day.
Classic Type II security failure... the people who belonged in the office couldn't get in, and therefore about two person-hours of employee time got lost never to be recovered.
The tighter a security policy is, the more things that could just plain go wrong and lead to access being denied to somebody who should be let in, causing a small calamity that is of course a whole lot less of a loss than a break-in, but still red ink that's going to have to go on the balance sheet. Too many such problems, and you can end up having it mounting up more losses to overtight security than if somebody had broken in and stolen what you were protecting in the first place.
What if the logs are forged? What if they got some hash of your password and they're locally trying to decrypt it?
Bad idea because of the obvious exploit... an attacker could DOS the entire user base in a handful of minutes by trying/failing each ID.
Of course, any BOFH might enjoy the "lockout the boss" feature included.
Interestingly, Lotus Domino uses a feature where as each attempt fails, the password prompt is delayed by a number of seconds. The delay increases exponentially, but never completely locks the user out. After a set period (minutes), the delay goes away and you start again. VERY effective in blocking brute force attacks...
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
which will help you perform random walks (a combinator term, not a calisthenics term) to generate strong passwords.
Which as many people here are saying - makes the security WEAK! Why? Because strong passwords that make system gatekeepers happy, make the users frustrated because they have a bunch of gibberish pws to change and remember. So while the Security People are all having a big circle jerk ("oh god! your big, long, random passwords feel soooo good", "ooh, your employee internet usage policy makes me tingle all over"), the users ARE WRITING ALL THEIR PASSWORDS DOWN.
Security idiot's response - Well, we'll make it a policy that they are not allowed to write down their passwords and this policy will be applied the same way that all security policies are applied - only to low level workers who we want to have an excuse to fire. (But not to the execs who surf porn and have a post-it with their passwords on the paperclip tray in their top righthand desk drawer.) This hypocracy is why employees view security in the same category as motivational programs and vision statements.
A human only needs to type in their password so fast. Login delays are the perfect solution to this.
If someone sees your encrypted password file, that is already a huge security breach.
Why chop off fingers or pluck eyeballs when
"Scraped up my fingers this weekend in a bicycle accident, and the stupid scanner doesn't recognize me. Can you open the door for me?"
or
"'Contacts have been irritating my eyes lately so the damn machine won't validate, can you buzz me in?"
work just as well?
Changing passwords frequently is a waste. Passwords should be changed when there is reason to believe they might have been compromised.
I know this is heretical, but it isn't silly. However, the other part really matters: quality. Passwords need to have significant entropy in them. They also need to never be reused across differing circumstances. In my current job I have lots of passwords to keep track of. Some are shared across different individuals (and should be changed when personel change), but others are chosen by me, and I don't reuse passwords.
When I need to generate a password I take (usually) 4-bytes of high quality random data and run them through a program called mnencode that turns the data into english words. I get things like magic-slang-crimson or inch-calypso-ibiza. Fairly easy to remember but much higher quality than most human dreamed up passwords.
Really annoying are circumstances where long passwords are not allowed. In those cases I remove vowels from one of these passwords.
How do I manage all these passwords? I use an inexpensive Palm Zire 31 with a copy of Gnu Keyring to encrypt all these passwords. For the master Gnu Keyring password I have a higher quality password than most, and I try to keep it secure.
I also have a Palm OS phone I could use for keeping passwords, but I don't trust it. It makes mysterious 10-second data calls all on its own. What is it doing? Also, it has needed service in the past. I don't want to trust my passwords to Sprint and their personel. Who knows what logging they might to keep the feds happy.
I don't trust the Zire 31 either, but it has no independent internet connection, if I keep it incommunicado I don't need to trust it so much, and it is cheap enough not to be worth servicing it
Further, I am very careful about not typing passwords on untrusted keyboards. I carry my own laptop I don't type passwords on internet cafe keyboards, for example. I don't log into my home machine from my work machine because I don't personally control my work machine. I use my notebook to log into home.
There is a case where I current do resuse passwords, and that is on personal Linux machines that I fully control, I use the same password for my personal account. I use the same password for root on all but one machine because on that one machine someone else also knows the root password, so it gets a unique password.
This is only good against dynamically calculated hashes; if you pre-hash the english dictionary or something like that, then once everyone has the hash table, we're back to square one when it comes to poor passwords.
Now back to why you want to do this. If the user forgets their password, you have it on file. No need to force change the password to something else, simply allow the user to go to an admin or a "password coordinator", who has the power to lookup a specific user's password. This needs to be done in person, no phone in's or anything of that sort, which allows you to verify with their badge/ID that they truely are who they say they are and then you give them the password for the account. This also relies on the fact that you need physical area level security that does not allow non-employee's into the area, but it is very secure (i.e. no emails, no phone calls, everything is done in person with reguards to passwords).
Now this also allows you to setup forced changes as well and password sync'ing across all systems (unless there is a reason not to, like system x is located in a public area which non-employee's can access). Otherwise with having everything using the same password for that user, they use it all the time and by process of repetition, they remember the password since everything (login screen, email, etc.) all use the same password across any system in the company/branch office.
Yes there is a danger in the sense that if someone gets the password they can access anything that person can do, but this is mitigated by placing a strict 30-45 day policy and running system and network level login logs as well as system based monitoring (i.e. something like SNARE) to track any attempted access to something they should not be looking at or trying to do, with email notification to IT security personnel when something odd occurs (like showing multiple logins at the same time on two physically different systems).
Not everyone can do something like this due to the increased overhead in terms to the IT department, but it is better then having they users pick passwords like "iamagod1" and lets you more easily keep tabs on all account activity to see exactly what may have been accessed.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
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.
Life is too short to proofread.
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.
>hoose easy-to-remember (and hence, likely easy-to-crack) passwords
Not necessarily. I mean depending on what the max character limit is he could be using pass-phrases. The password is becoming obselete and the pass-phrase will be the next step. That is if the next step isn't smart card keys, challenge response you can do on a PDA, etc.
Of course the pass-phrase has its flaws too like using famous quotes, but that could be screened out the same way common words are. There might be some side benefits to this. Personally, I find phrases easier to remember than words, even if they have numbers or odd characters in them.
I think passphrases and encrypting communications will go a long way towards security. A lot of good that killer password does you when you send it in plain-text when you use FTP or POP3. In fact , a lot of password policies are based on the fact that you will use ftp or pop or something and eventually you will be sniffed so changing your password more often is a long term fix before they can roll out ssh, sftp, and ssl-pop/imap or whatever. If they're even planning it. Eventually we're going to look back to the 90s and early 21st century and think "whoa, I sent all that crap unencrypted?"
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.
All theory is gray
Every computer needs either a smart-card slot or an iButton reader, and by logging in with that, you ought to be able to do challenge-response or rolling-code authentication on every system to which you are allowed access, with the key doing the computations on board. Passwords ought to be obsolete by now, or supplementary in ultra-high-security systems only. Certainly by the time the sysadmins decide that they have to be so long and changed so often, that you haven't a prayer of remembering them, then it's high time to replace them with something else.
No password cracking scheme based on brute force can work under these conditions. Say it allows 5 attempts before locking you out for an hour and 5 more the second time. You get a total of 10 attempts. Someone with no knowledge of the user (so social engineering can't be used to get info which might lead to the password) or the password itself via a keylogger (which, as the parent wrote, is still a security issue), cannot hope to guess the password with any practical degree of probability. This essentially eliminates the technical security problem, leaving only the human element, which is susceptible to social engineering attacks.
http://neokosmos.blogsome.com
First of all, they could put their passwords on post-its in the locking drawers most desks have. Almost as convenient, but MUCH more secure.
Also, there are plenty of ways to have greater security than completely out-in-the-open Post-It notes with passwords. For guys, keeping the password list in a wallet, purse, or at least desk drawer that could be locked would at least add some physical security.
Actually, keeping the passwords on the monitor wouldn't be too bad if the passwords were obscured some way. For example, list the passwords incorrectly, but make the first letter of each incorrect password be the first password, the second letter of each in order the second password, etc. Reasonably easy to look up, but not obvious enough to be tempting. A slightly more complex scheme would probably be useful, perhaps hiding the password in seemingly legitimate post-it notes. Making the password the second letter of each word in a fake Post-It note would be better. This would allow routine password changes with just a little work, without being quite so blatant about having them out in the open.
Security, for most workers, needs to be balanced with usability. Truly random alphanumeric passwords are not reasonable to memorize. A better route would be to teach each user a mnemonic method of choosing a password (i.e. password from initial letters of words in chorus of song or famous quote -- if numbers are required convert every other one to numbers as if it were a phone number [ABC -> 2, DEF -> 3, etc., which is easy to convert in an office environment because everyone has a phone readily accessible]. If each person has a slightly different scheme, this can be a very easy way of getting hard to crack passwords that are very easily memorable.
Fancy algoriths..
..)
You need 3 things:
1. Keep your pw hashes out of users range (/etc/shadow)
2. Turnoff any non SSL (Telnet, ftp,
3. A big sleep(5) in the login program.
If all this are done, then the only way to get in are to bruteforce and "try and error". Even if the algorithm used is done in 5millisecond, you can try an other time within 5 seconds. Thats a _big_ delay.. And its always going to be, no mather how fast new computers become.
We used to have an agreement on password security I liked a lot in the physics departmant: Choose any password you like and change it as often or rarely as you like. Just be aware there is a little cracking program running in the background which will disable your account if it succeeds. And btw. all those lucky fellows also had to bring a cake to the christmas party.
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.
Are you trying to say that that is an easy to guess password? Because I'd never have tried it. A better story would have been that his password was "drew" or "dean" or "password". All I'm trying to say is that "dddrewww" is nowhere near "the simplest password."
Support the First Amendment. Read at -1
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.
I agree with this, although the people enforcing the passwords should really be asking what level of security do they need. Forcing people to have the most complex passwords possible all the time encourages people to write them down on a post it note and stick it to their monitor.
There are different levels of security needed - an email password is usually not as important as a banking password, so forcing them both to abide by the same security rules seems wrong - the banking password should indeed be very strong since there is an incentive for someone to break it, whereas the email password is not especially important and it is probably worth allowing the user to have a slightly more memorable password.
There is also some self-discipline involved here - users should be encouraged to have a number of passwords for different levels of security - it is a good compromise between one password for everything (not a good idea) and a different password for everything (impossible to remember). I myself have a few levels of passwords:
Root password
Normal user password
Banking password
Password for stuff I don't really care about (mailing lists, etc).
I think sooner or later we will stop using complex passwords and instead use a challenge/response system - the user can carry a key around with them which they could plug into a USB port, etc. The server connects to the key over the network and does a cryptographic challenge. The key sends a cryptographic response to the challenge which confirms it's identity. It would probably be wise to have the user enter a PIN to prevent someone immediately using the key if it is stolen.
This has many advantages over passwords:
- it is actually something physical - you know when it's been stolen and can revoke it ASAP
- if designed correctly, the key is essentially uncopyable since it never reveals it's encryption key
- both the key and the server systems can be designed to reduce the ability to brute force the keys - the server can induce a delay after an incorrect response, the key can do the same if you enter the PIN incorrectly. And the key could be designed to destroy itself if the pin is entered incorrectly too many times.
This type of system would be by no means costly and would be far more secure than the current system involving people actually having to use their brains.
http://blog.nexusuk.org
My comments do not necessarily reflect my own opinions.
What I never got was this: If I have a password, and no one else ever knows it, AND I check my logs so I know if someone is trying to hack my account, what good does changing it anyway?
/etc/shadow (which would allow them to brute-force it at a reasonable speed without leaving traces in your logs) and you didn't just give your password to some random person then you're pretty much fine.
Yep, I don't think there is a need to change passwords until someone uses one to compromise your system: if you change passwords every 6 months, what are the chances that someone cracking it coincides with you changing it. If someone cracks your password they're going to use it immediately, not wait 6 months until you change it.
The biggest problem with users is that they don't give any thought to security so are open to social engineering...
"Hello, this is the system administrator - I'm investigating a problem with your email and I need your password to check it"
"Oh ok, it's 'Fubar'"
Did you check that that was actually the sysadmin? nope.
Does the sysadmin even need your password to access your email? unlikely.
So long as noone gets hold of your
http://blog.nexusuk.org
Who do you think will be behind that change? At some point, someone will come up with an idea that will be the start of this new system. It could be a slashdot reader. The idea could come today. The people behind Google must have come up with an idea one day a few years ago, and at the time it was probably nothing more than an idea that started with, "what if there was a search engine that could..."
Slashdot might be the kind of environment where a new idea for the future of authentication could be born. So go ahead and panic, spleculate, and worry. If that leads to a new idea, do something with it. That is how we come up with new stuff.
Oh, and do something with it that protects yourself from lawsuits from the big companies in the future, while still allowing open source software to someday implement it.
I really hate signatures, but go to my website.
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.
Someone I work with asked about how he should protect a key to a secured area, and the response was "How often do you lose your car or house keys? Keep it with those." I'd say the same applies to your wallet and keeping passwords in it, if worse comes to worse and you can't remember them.
Considering I've never lost my wallet, keep everything shy of my birth certificiate in it, and will know instantly if it's gone and can report it, I'd say that's pretty secure. I carry it so consistently I feel noticeably strange if it's not in my pocket.