Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Passwords - 64 Characters, Changed Daily?

timothy posted more than 9 years ago | from the too-much-overkill-is-never-enough dept.

Security 645

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.)"

cancel ×

645 comments

Just do what I do (5, Funny)

thammoud (193905) | more than 9 years ago | (#9915331)

password1 password2 password3 password4 based on the month that you are in.

Re:Just do what I do (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9915351)

Thanks for your input jerk off.

Re:Just do what I do (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9915363)

Well, thanks for yours, Asshat.

Re:Just do what I do (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9915374)

You're welcome.

Re:Just do what I do (5, Funny)

Anonymous Coward | more than 9 years ago | (#9915376)

just checked, you don't do that.

Re:Just do what I do (5, Insightful)

Abcd1234 (188840) | more than 9 years ago | (#9915406)

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:Just do what I do (0)

Anonymous Coward | more than 9 years ago | (#9915412)

hey, its not funny... as password requirements get larger, people will use such techniques to generate them.

I use something like January99A for my passwords after work instilled new password requirements - minimum 8 characters, of which there must be a character from each of letters, numbers, capital letters, punctuation. Changed monthly. (I think some sysadmin got check-happy on the password policy dialog).

If it wasn't for that policy, I could use a pass-phrase instead of a password, and remember it!

Re:Just do what I do (2, Interesting)

fastfingers55 (803824) | more than 9 years ago | (#9915463)

Our system requires that the new password have at least 3 characters different from the previous one. So that scheme would not work. Nor would password001 password002... The idea of using an abreviation for the month falls apart too. For example: passwordjun passwordjul passwordaug all do not change enough.

Re:Just do what I do (2, Insightful)

DaZedAdAm (131819) | more than 9 years ago | (#9915510)

However, password111 password222 password333 and such would work. I can't imagine that would be any harder for someone only slightly modifying their passwords.

Re:Just do what I do (1)

Temfate (753891) | more than 9 years ago | (#9915475)

The scary thing is this is almost exactly what it's coming to. The more systems that one has password access to, the more likely that he/she will begin to choose passwords that have some correlation to that system. I mean accept the fact that good computer users that understand security will never use the same password twice (given this might not happen, but consider it). How many systems does the average IT tech have access to? Include all forums you have to log in to, and everything else that uses a password. I personally would have to memorize almost 32 passwords and be able to remember all of them at any given time. The sheer quantity of security measures will be what destroys security.

This article is sooooo gay.... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9915332)

Much like Slashdot itself.

Re:This article is sooooo gay.... (-1, Offtopic)

EpsCylonB (307640) | more than 9 years ago | (#9915366)

Godamn cock sucking fcc...

Simple... (2)

Doomrat (615771) | more than 9 years ago | (#9915337)

Seems simple - restricting the number of times you are allowed to get in password incorrect before the account is suspended. It doesn't matter how much processing power you might have if you're only allowed three guesses.

Yes, this might be inconvenient, but most of life has been made this way due to criminal activity.

I'd be interested in hearing how this way might not work. It's very possible that there's some sort of loophole, although it seems like you couldn't possibly bypass a guess limit.

Re:Simple... (1, Redundant)

Omega697 (586982) | more than 9 years ago | (#9915361)

Hell, give it 1000 tries. Nobody is going to get their own password wrong 1000 times in a row.

Re:Simple... (3, Insightful)

XaXXon (202882) | more than 9 years ago | (#9915377)

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:Simple... (1, Offtopic)

XaXXon (202882) | more than 9 years ago | (#9915394)

oops, that 5th word was supposed to be "not" not "now".

Crap, I hate it when the typo is still correct English.. People read right through it and assume you're dumb instead of just not being able to type (or proofread).

Ah well.

Re:Simple... (2, Informative)

Anonymous Coward | more than 9 years ago | (#9915447)

you get a hold of the encrypted password and check against that

The days when anyone on a system could just get all the encrypted passwords are long-gone. Getting encrypted passwords requires a root compromise these days. We not in the 90s anymore. :)

Re:Simple... (4, Insightful)

gl4ss (559668) | more than 9 years ago | (#9915440)

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)

Re:Simple... (1)

whysanity (231556) | more than 9 years ago | (#9915492)

This is exactly how it is at my work (a University). If you try to log on to your network account, you must get it right within 3 attempts or have it manually reset. I found this out just before figuring out someone left CAPS on.

Good news for hacker (5, Funny)

usefool (798755) | more than 9 years ago | (#9915338)

Wasn't there a joke that if users are required to change password every second, hackers just need to keep on trying the same password until users themselves changed to match the hacker's password?

Biometrics (1)

Jorkapp (684095) | more than 9 years ago | (#9915341)

One day we'll have Biometrics, so we won't have to remember our passwords.

Re:Biometrics (4, Funny)

wkitchen (581276) | more than 9 years ago | (#9915375)

Oh, that'll be just great. Chopping off fingers and plucking out eyeballs will be the new definition of "social engineering".

Re:Biometrics (1)

crackshoe (751995) | more than 9 years ago | (#9915422)

well, you can synthesize finger and palm prints, so the whole finger-choppy bit isn't necesary. but who doesn't want to keep eyeballs around in jars, eh?

Re:Biometrics (1)

Frequency Domain (601421) | more than 9 years ago | (#9915399)

The problem with biometrics is that the data can't be changed or revoked, and it is recordable and replayable.

Re:Biometrics (5, Insightful)

Blastrogath (579992) | more than 9 years ago | (#9915423)

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:Biometrics (2, Interesting)

molafson (716807) | more than 9 years ago | (#9915485)

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.

That is why it is better to use both: a good pass-phrase that you change from time to time, which is hashed together with your retinal scan, finger print, etc.

Re:Biometrics...only two thumbs (1)

farrellj (563) | more than 9 years ago | (#9915456)

Biometrics are a nice idea, but what happens when someone compromises your account? You have to start using your other thumb...and if that is compromised?

No, we need multi-element authentication systems that challenge users on more fronts. Tools like the ACE server, where you need you login, password and token number from a frob is a start. More work needs to be done on this problem, though.

ttyl
Farrell

Yeah right... (3, Insightful)

imsabbel (611519) | more than 9 years ago | (#9915521)

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

law (0)

Anonymous Coward | more than 9 years ago | (#9915342)

if moores law continues you should probably have to change your password every twenty to thirty seconds

One time use? (5, Informative)

slykens (85844) | more than 9 years ago | (#9915344)

SecurID and its like are your friends.

While you maintain a reasonably secure password you're not logging in without the token.

hjhjghfgj (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9915345)

jhggfgfhgdf

Use a CueCat (5, Insightful)

Safety Cap (253500) | more than 9 years ago | (#9915348)

, 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.

Re:Use a CueCat (1)

Frequency Domain (601421) | more than 9 years ago | (#9915444)

That's one variant of the "bring something, know something" approach. Public key based challenge/response systems where the response is generated by an independent computing token such as a Java iButton or smart card is another example.

Re:Use a CueCat (2, Interesting)

the_mad_poster (640772) | more than 9 years ago | (#9915449)

Heh heh... ironically, the CueCat wasn't exactly the height of security back in the day, and most Slashdotters who have one have probably long since removed the eeprom that transmitted the cat's real unique id.

Re:Use a CueCat (2, Insightful)

omicronish (750174) | more than 9 years ago | (#9915452)

What happens if you lose your CueCat?

Re:Use a CueCat (0)

Anonymous Coward | more than 9 years ago | (#9915529)

..as reported in the current issue of 2600. They recommend storing the string generated (It's plaintext) somewhere secret, encrypted with a remember-able passkey.

Length & Considerations (5, Funny)

Oculus Habent (562837) | more than 9 years ago | (#9915353)

I could see a password of substantial length made of a phrase. Say, 64+ characters, changed every two weeks might be fine. Especially if you have a well-read workforce, which might enjoy making note of significant passages.

You might want to [optionally] be able to use the first letter of each word as a "shorthand" password for re-verification moments, because typing in a 64+ character phrase everytime you lock your station could become tedious if you are away from your desk often.

Alternately, if you have a number of services at work that should have different password, some sort of secure password comparison tool could be employed to at least ensure that employees aren't using the same password for everything. Not sure about an architecture for that, though.

Pointless (5, Insightful)

jolyonr (560227) | more than 9 years ago | (#9915358)

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.

frequency and plausable deniability (1)

spoonyfork (23307) | more than 9 years ago | (#9915360)

How about a password that you don't know and changes every 60 seconds? [rsasecurity.com]

Mod parent up (1)

ca1v1n (135902) | more than 9 years ago | (#9915486)

These systems are absolutely wonderful. Of course, access to the card itself is an issue, that's why they use two-factor authentication.

Requiring users to frequently change gibberish passwords tends to be much less secure than either frequently changed non-gibberish passwords or long-term gibberish passwords, because the users forget them, and either spend a lot of time on the phone with IT (social engineering waiting to happen, many IT shops are happy to authenticate users over the phone by DOB and SSN, which are easy to come by,) or write it down in obvious places if IT is annoying about password change requests (which it should be).

Won't work that way (0)

Anonymous Coward | more than 9 years ago | (#9915364)

Most systems limit the number of login attempts in a period of time. This isn't the same as an endless attempt at guessing passwords/keys.

password changes (1)

onepoint (301486) | more than 9 years ago | (#9915365)

we will have to consistently upgrade our change cycle, currently you are at 90 days, you will most likely go to 60 within 9 months, then 30 within 6 month after .... then once you reach a certain point you will have to expand your password from 10 to about 14

Delays (2, Insightful)

bobintetley (643462) | more than 9 years ago | (#9915367)

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.

Keys (0)

Anonymous Coward | more than 9 years ago | (#9915368)

Maybe you will carry a 10MB randomly generated key on a usb type of deal... And you will need physical presence with a machine to give it, even if the file is network transmitted.

Exponential growth problem (5, Insightful)

Kufat (563166) | more than 9 years ago | (#9915369)

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.

Re:Exponential growth problem (0)

Anonymous Coward | more than 9 years ago | (#9915439)

"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"

Except that the last two characters are guaranteed to be the month-number, if you need a new password every month. So they only increase the passwordspace by about 1 times.

Re:Exponential growth problem (1)

theM_xl (760570) | more than 9 years ago | (#9915471)

Like say, any American intelligence agency? Okay, so we're too late on that score.

Re:Exponential growth problem (1)

Wesley Felter (138342) | more than 9 years ago | (#9915526)

But all characters aren't equally likely. IIRC, each additional character only adds 1.5-2 bits of information to the password. If you want the information in passwords to track Moore's Law you'd need to increase the length by one character every two years or so.

u are wrong (0)

Anonymous Coward | more than 9 years ago | (#9915370)

Processing power increases linearly, adding characters to your password increases complexity geometrically

What's the problem? (1)

Jugalator (259273) | more than 9 years ago | (#9915372)

Just pick a long easy to remember password...?

It's much harder to brute force crack a 11 character password than a 10 character and so on, so I don't really see the problem.

A good way to make it easy to remember without restorting to mangled ASCII is to pick the first letter in a sentence you know (or the two first... you get the idea). You can end it with some other code you know since before, and you're set.

Bad assumption (5, Insightful)

Phexro (9814) | more than 9 years ago | (#9915373)

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 (4, Insightful)

grumbel (592662) | more than 9 years ago | (#9915509)

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.

SecureID (1)

D3 (31029) | more than 9 years ago | (#9915380)

Our company uses tokens that change every 60 seconds. Try and guess that one with your computer. Password length is a minimum of 11 characters.

It isn't that hard.

Re:SecureID (0)

Anonymous Coward | more than 9 years ago | (#9915470)

Using securid is fine getting on to your own network. But, what if you want access to someone elses? Do you have a securid for your bank, stock brokerage account, 401k, each credit card company, etc.? We'll all look like janitors with the huge number of securid tokens hanging off our keychain.

Re:SecureID (0)

Anonymous Coward | more than 9 years ago | (#9915474)

Of course if the bad guys want to crack your system, they just kill you and take your hardware device. That's the way car theft is going these days. You can't hot wire the car anymore so you just take the car while the driver is in it.

Keys and locks keep the honest people out. The bad guys will always find a way.

Duh (1)

Admiral Llama (2826) | more than 9 years ago | (#9915384)

How about a (some large number)-bit DSA key on one of those USB thumbdisk thingamabobbers? Sun has those smart cards that get used for authentication, I'm sure one of those might come in handy too.

As for passwords your average Joe six-pack/soccer mom is going to remember... they're easily cracked anyway, I fail to see what difference the future will bring.

Non-user-dependent security (1)

scowling (215030) | more than 9 years ago | (#9915390)

It strikes me that if you have to require your end users to constantly change their passwords in order to prevent them from being cracked, that's your entire problem.

Instead, you should be securing your system to prevent password lists being downloaded and to prevent multiple subsequent incorrect logins.

Secure your own system. Don't expect your users to do it for you.

Re:Non-user-dependent security (1)

Blastrogath (579992) | more than 9 years ago | (#9915490)

It strikes me that if you have to require your end users to constantly change their passwords in order to prevent them from being cracked, that's your entire problem.


Instead, you should be securing your system to prevent password lists being downloaded and to prevent multiple subsequent incorrect logins.

Secure your own system. Don't expect your users to do it for you.


No matter how secure you think your system is, you should not act as if it was invincible. Requiring password lenth and periodic changes is an additional layer of security, and more security is better than less.

As long as you balance your password requirements against the potential for users to start messing them up out of frustration then you should be ok.

Re:Non-user-dependent security (1)

sonicattack (554038) | more than 9 years ago | (#9915513)

Instead, you should be securing your system to prevent password lists being downloaded and to prevent multiple subsequent incorrect logins.

My first reaction - then I thought of the possibility to sniff the network and thus gain access to the hashes.

I believe token systems such as Kerberos has a better solution, where the hashed password isn't sent over the network.

The future of passwords (1)

davidwr (791652) | more than 9 years ago | (#9915391)

I see the future as being "something you have, plus something you know."

As one example among many, Lotus Notes has had this for years. What you have - an "ID file" on disk - and what you know - the password to that ID file - get turned into a presumably-hard-to-crack identifier.

20 years from now, you'll just have to present your employee id card or thumbprint to access your office computer or the Internet, then enter a reasonably-short password, in case someone chops off your hand or steals your badge.

The real question isn't password-change requirements, it's ID management:
Will you be ALLOWED to have multiple, non-linked, IDs to access different services, or will you be REQUIRED to use something like MS's Passport, and be prohibited by law from having multiple IDs?

Slow down, cowboy! (1)

Jetson (176002) | more than 9 years ago | (#9915393)

I really don't want [...] 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.

In order to crack a password you need to know the hashing formula and the expected result. If either is unknown then the only way to perform an attack (dictionary or otherwise) is to ask the protected service to validate each attempt. In that case, a simple time delay in the authentication procedure would stop most brute-force attacks. In *nix the hash result was moved from /etc/passwd to /etc/shadow for this reason.

try 15+ (0)

Anonymous Coward | more than 9 years ago | (#9915395)

For windows boxen 15+ is the sensible requirement since they won't be tempted to store/use lanman hashes for those lengths. Lanman hashes are very crackable using for instance rainbow crack.
Also use unicode character(s).

Complex ever-changing passwords are easy (1)

Rosco P. Coltrane (209368) | more than 9 years ago | (#9915396)

I have my own system here: instead of learning one or more passwords, I've learned a small formula that I made up, that use the first 5 letters in a hostname and the date, and spews out a alphanumerical string.

On my main box, where I log in often, the script never updates my password and the date is always set to the epoch, so I always use the same password. On boxes on which I log in infrequently, I have a small program to change the password every day, and I have to recalculate the password for the day. It's kind of a pain, but at least I can have accounts of dozens of boxes and not have to remember all the passwords, and the passwords change all the time and resist to dictionary-based attacks.

Of course, if I ever reveal the formula, I'm dead :-)

The problem is the input device, not pass length (1, Funny)

GuyFawkes (729054) | more than 9 years ago | (#9915408)


typing
kGNisksUI725K-{P#~iuiILl896&Tui@'p;p'HHP O~9yu* *(

is going to be a pain in the ass for anyone if the input method is always going to be a qwerty keyboard...

on the other hand a 20 dollar mongrel dog that I feed every day will never mistake me for anyone else...

_electronic_ based biometrics however will completely suck

Moot point (0)

Anonymous Coward | more than 9 years ago | (#9915411)

As I've posted before (sorry, AC's dont have posting history, so I can't refer you to the original), this is a moot point if you impose a 1 millisecond delay after every password attempt (successful or not).

A random 8-character password (with 62 possible values for each character: 26 lowercase, 26 uppercase, 10 digits) has 62^8 or 218,340,105,584,896 possible combinations. If we take that number of millisconds and convert to years, the result is 6,918.9 years. So with a 1-millisecond delay per password attempt, it would take nearly 3,500 years (on average) to hack it by brute force. And any clueful sysadmin would discover that someone's been trying to hack the password long before that happened.

Shoot, you could even drop the lockout to 10 microseconds if you're willing to accept a greater risk of someone hacking the password in your lifetime (35 years to hack it by brute force). Though a 1% risk of having your password cracked in 4 months may be too risky for some people...

Cost of Passwords vs. Cost of Incursion (2, Interesting)

G4from128k (686170) | more than 9 years ago | (#9915414)

At what point in time do employees spend more time (= money) creating, remembering and retreiving inscutable passwords than they spend recovering from hacker incursions. An employee's ability to handle rapidily changing, complex passwords is fixed by evolution whereas, hackers abilities to break or phish passwords is only going to increase. At some point the curves will cross and organizations will spend more to keep things locked than they lose with leaky passwords.

Normal users (5, Interesting)

Skiron (735617) | more than 9 years ago | (#9915416)

In my opinion as a Sysadmin, it doesn't matter what device[s] you bring in to try to 'secure' users and passwords.

They still write them down, still 'share' (if somebody hasn't got access to a file share the other has, but he/she wants them to look at something - (they don't even *think* about the option to copy it to a public share to do it!) - then they give out passwords.

Plus normal users forget them after a few days of work anyway - I reset usually around 5 passwords Monday mornings after people had two days off work - plus average 10 a week afterwards on a user base of 150.

Passphrases (1)

Poor College Student (657160) | more than 9 years ago | (#9915418)

Try a nonsense phrase, such as:
King Andy Gumps reign below all evil caviar for last 5 weeks special.

Its not likely to be vulnerable to a dictionary attack and since its a nonsense phrase, most of the word pairs arent likely to be used together -- as opposed to "Happy Birthday" (ok, Andy Gump is a pair)

Anderson's formula. (5, Informative)

Anonymous Coward | more than 9 years ago | (#9915419)

How long does it take? Use Anderson's formula to figure it out.

T = N/(PG)

In this:
  1. T: The time units needed to guess the password
  2. G: The guess rate, or the number of attempts to guess the password in a single time unit
  3. P: The probability you want that the password is guessed. (Or use '1-P' to go the other direction.
  4. N: The number of possible passwords, usually A^l, where
    1. A: Alphabet used for passwords. E.g., There are 96 printable ascii characters often used in passwords. Or maybe its case insensitive, so subtract 26.
    2. l: The number of characters in the minimum password.


So, let's say you want only a 10% chance your password is guessed. And you estimate an attacker can perform 2,000,000 guesses per second with his drone army. The passwords are from an alphabet of 26 characters, and are a minimum of 4 characters long. That means... (tappity, tappity on the TI calculator)... Um, that means you'll be hacked instantly. :)

Read more on Anderson's formula by googling. :)

Re:Anderson's formula. (0)

Anonymous Coward | more than 9 years ago | (#9915466)

Also, I forgot to cite a good password generation link. Check out the http://www.itl.nist.gov/fipspubs/fip181.htm [nist.gov] APG system, fips 181, which will help you perform random walks (a combinator term, not a calisthenics term) to generate strong passwords.

Bad Password Delay (1, Insightful)

novas007 (411673) | more than 9 years ago | (#9915420)

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.

who uses passwords? (1)

spoonist (32012) | more than 9 years ago | (#9915425)

who uses passwords to crack into systems?

there are SO DAMNED MANY easy exploits that will get you root or admin, that you don't usually need passwords to crack into systems...

that said, there is still a balance to maintain. passwords like "password" are just lame and too easy... a good 6-8 character password with letters, numbers, other will keep anyone from guessing passwords at random.

but you still have to lock down your systems to keep out those pesky remote sploits.

(also, the best password in the world is no good if you throw it across the 'net via telnet, http, and other unecrypted protocols.)

good passwords are just PART of the overall game of system security

Where I work... (1)

Liquidrage (640463) | more than 9 years ago | (#9915426)

You can tell how long a person has been with the department by the numbers at the end of thier password.

myLittlePony24 They've been there at least 4 years

darthVaderRulez4 Newbie


What I don't like about all the new password rules like miniumum of 8 characters, must have a special character and a number, change ever X days, etc... is:
They ignore the social engineering aspect.

Walk around where I work after hours and after fun logging in as other people simply by reading the post-it notes stuck on their monitor.

It's hard to concinve the operations people that there's a happy medium in regards to password rules. By making them too strict they actually seem to make them easier to break because people don't remember hard passwords very easily. Espeically since we're generally talking about non-IT people.

So in regards to the topic, I'm hoping that within a few years places learn to respect the social engineering side and find a happy medium in regards to password rules.

Moore's Law? (1)

einer (459199) | more than 9 years ago | (#9915434)

I think Moore's law only makes a difference when the attacker has a copy your password shadow file. What is stopping me from changing what is stored in that file into something much more difficult to attack (a stronger hash)? Moore's law doesn't attack password strength, it attacks the strength of the algorithm that turns your password into the hash in shadow.

i prefer thumbdrives (1)

prockcore (543967) | more than 9 years ago | (#9915437)

I prefer the concept of storing a large key on your thumbdrive, which you then need to plug in in order to log into your machine.

It's all getting out of hand (1)

DeepDarkSky (111382) | more than 9 years ago | (#9915438)

I mean, quite frankly, even as processing power increase, the human ability to remember password is not exactly getting better. There are techniques, such as mnemonics to help with remember long generally difficult to guess/remember passwords, but these techniques are already there. Typed in password formats themselves can't really change much anymore. Biometric authentication will probably have to be the way to go.

There's just no foreseeable way that existing password systems can be used to maintain systems that need to be absolutely secure.

On the other hand, I wish we'd just not need to have all this security and all these passwords.

It's not such a big deal. (1, Insightful)

Anonymous Coward | more than 9 years ago | (#9915442)

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.

Passwords are so 1999 (1)

tarkie101 (702538) | more than 9 years ago | (#9915445)

If your company is updating from a six character password, its about time too! Six characters is WAY to low, especially if that standard applied to administrator or root accounts. SANS now recommend using Passphrases, not passwords, as the LENGTH of the password, not the complexity gives the overall strength of the passphrase. A 14 character password, to all intents and purposes, is uncrackable due to the length of time it would take to brute the password.

makemeapassword.com (4, Interesting)

mgkimsal2 (200677) | more than 9 years ago | (#9915451)

Not a perfect system, but is something which can help people come up with something more secure than 'password' while incorporating numbers and punctuation marks.

makemeapassword.com [makemeapassword.com]

Forget biometrics and excessively long passwords (1)

marm (144733) | more than 9 years ago | (#9915453)

a simpler solution would be to make the password hashing algorithm much more complex and CPU-intensive.

MD5 and SHA1 are just too fast. If a new hashing algorithm was used that took a second to compute rather than the microsecond or less that an MD5 hash takes, it would make brute-force or dictionary attacks on the password much much more difficult, but wouldn't really get in the way of people logging in - it's only a second.

Bah (1)

PrvtBurrito (557287) | more than 9 years ago | (#9915454)

Passwords are not the issue. This is such a stupid debate. Hacking passwords by dictionary attacks are preventable and protectable. Even the simplest password is difficult to predict without trying *a lot* Perhaps instead of bitching about passwords to their users, administrators should bitch about insecure oses that can't detect these attacks. Why on earth should all the users of the world worry about passwords, when a couple of groups of people could implement a system to prevent this.

Re:Bah (1)

t_allardyce (48447) | more than 9 years ago | (#9915527)

I think most password cracking comes from looking at the postit-note next to the keyboard, trying their name and then resorting to "suckmydick". Most intrusion isnt from outsiders trying sophisticated attacks on obscure buffer overflows (although that doesnt mean its ok) but from someone who looked over your shoulder and is browsing your files now you've gone to lunch. Common sense security precautions are the thing you have to teach first.

We would expect certificates as standard (1)

arivanov (12034) | more than 9 years ago | (#9915464)

Passwords have been considered an overly weak form of auth for anything important for many years now. If you want to have proper auth use something that is based on strong crypto (x509 certs, RSA/DSA keys, etc) and the password is not a password, it is passphrase. This requires stealing the private key in order to authenticate, which raises the stakes considerably.

Best practice is to double layer it by using x509 or RSA/DSA for authenticating a machine followed time password using the cert to select the correct sequence.

There are bundled implementations which do this. SecureID is a good example - AFAIK it is based on some form of RSA keys and one of the RC algorithms. Unfortunately the private part is stored at both ends which run the same crypto transform to reach the same result using the time as an IV. There are better (to be more exact - correctly designed) implementations from other vendors as well which use REAL public/private crypto.

Unfortunately very few of them work under anything but windows, which has its explanation. No matter how much do I dislike Microsh**t, it has a standartized crypto framework and if you want to replace the default shite with proper auth you can do it. You can cleanly introduce certificates, hardware extensions, you name it. You can even do it by means that are clearly in the DIY category.

Linux does not have it and it is a logical result from the many years during which crypto was excluded as a matter of policy from the mainline kernel. Thanks god it is over now, so we might see proper auth framework for linux sometimes in the future.

What about /etc/shadow? (1)

Adrian Lopez (2615) | more than 9 years ago | (#9915465)

The only way hackers can check passwords quickly enough to matter is if they manage to obtain access to the file that contains the checksums for the users' passwords. In Linux, at least, this is /etc/shadow, which can only be accessed by root. If a hacker has access to the files owned by root then you have much bigger problems than a hacker trying to guess at users' passwords.

Passwords (1)

CastrTroy (595695) | more than 9 years ago | (#9915468)

The problem that I have with passwords is that I have so damn many of them. I keep them in a password storing program on my palm. It generates random passwords when I need to create a new one. It's all encrypted under a password that I think is significantly hard to crack for the information I have in there. The program that I use can be found at http://gnukeyring.sourceforge.net

Perhaps make it more user friendly.. (5, Funny)

t_allardyce (48447) | more than 9 years ago | (#9915476)

Windows XPs new password policy manager: "Im sorry, that password has already been taken by user john, please choose another"

passwords don't have to be longer (1)

hkon (46756) | more than 9 years ago | (#9915481)

crypts just have to be more computationally intensive. If you could come up with a crypt that was much harder to compute, brute-forcing it would be much harder, and you've solved your problem.

Use the Bible (0)

JeffTL (667728) | more than 9 years ago | (#9915484)

Then you just tell people that the password is "Genesis 1:5 KJV" and they can remember something like that, and look up the verse when they need to have root access to the server. Pick out a new verse from the Bible, or part of the Constitution or what have you ("Article I Section 2 clause 5" can be remembered better than "the house of representatives shall choose their speaker and other officers and shall have the sole power of impeachment," a very secure password for high-security systems.) Just change the password and source from time to time, perhaps weekly or monthly.

There isn't a problem (2, Insightful)

89cents (589228) | more than 9 years ago | (#9915487)

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.

I don't see the problem at all! (5, Funny)

termos (634980) | more than 9 years ago | (#9915489)

Luckily I have Gator [gator.com] for remembering all my passwords!

One time pad (1)

vulcan_pupil (718417) | more than 9 years ago | (#9915493)

I personally think an implementation of a one-time pad is a rather secure way to go. If someone does happen to capture your unecrypted PW, so what. The same PW is only used once. I will be implementing this on my FreeBSD box soon. If interested, here are the basics [freebsd.org] on how to do this with FreeBSD.

Your password requirements are already too weak (1)

Occams Razor (83673) | more than 9 years ago | (#9915494)

Passwords of 8 characters can be broken in seconds, no matter what character set you use or how random they are. Password lifespans of months are pretty much worthless and just provide proof that your company is following "industry best practices" (even though those aren't "best practices").

Go to tokens and biometrics and passwords that are used to access those data sources. Have them generate long random strings that are changed constantly and are authenticated using digital signatures from your personal certificates that are stored on devices that never leave your person and require additional authentication to use.

Then you'll be a little safer.

Hmm (3, Insightful)

Erwos (553607) | more than 9 years ago | (#9915514)

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

crack ratio (2, Informative)

epine (68316) | more than 9 years ago | (#9915515)

Good grief, people. The size of the password space determines the ratio of the time it takes to check the *entire* password space vs checking only the correct password (normal logon).

The *absolute* time taken to crack the password space is therefore a function of how long it takes to check a *single* password. This can be any length of time the password validation system wishes to implement (relative to a fixed processing resource).

There's no reason at all why passwords need to evolve to greater lengths as computers become faster. However, this inflation happens by default if the authentication system does not compensate by implementing constant time password validation as systems become faster.

A modern computer can validate a password in one microsecond that would have taken one millisecond back in the VAX days. This is one case where increased speed is not, in fact, a good thing.

Biometrics or Tokens (1)

Monkelectric (546685) | more than 9 years ago | (#9915518)

If your application needs to be *THAT* secure, you need a device like the Digital Persona [digitalpersona.com] , or the Security Ibutton [ibutton.com] .

I would use the crypto ibutton as an authentication scheme, possibl storing the password.

Something you know, you have, and you are (4, Interesting)

jncook (4617) | more than 9 years ago | (#9915519)

To quote Bruce Perens, if security really matters, you should base it on three things:

* Something you know (password or PIN)
* Something you have (badge or bank card)
* Something you are (thumbprint, hand scan, voice check)

This is how CounterPane security locks up its own colo facility. (Of course, they also tape everybody coming in, and there's a live guard who knows your face.)

Each of these components can be relatively weak, but in combination they are quite strong. For instance, you could probably let people choose any password they wanted as long as you required, say, their badge and a thumbprint to log on.

For backwards compatibility, write a macro that generates random strings of characters the maximum length accepted by the legacy system to which you must log on. Encrypt the list of passwords, and use the method above to decrypt the password archive as needed.

James

Law of unintended consequences (1)

rumblin'rabbit (711865) | more than 9 years ago | (#9915524)

When dealing with people, the law of unintended consequences is king.

When you make things too difficult for people, things get less, not more, secure. Remembering one's password becomes a real problem, so people start writing them on notes and sticking them on their monitors, or changing them in a predictable way (skooby_aug04, skooby_nov04, skooby_feb05).

The remembered and typed password has its limits. Some of the other ideas posted in this forum are a better way to improve security.

New Idea (1, Insightful)

Malicious (567158) | more than 9 years ago | (#9915528)

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.

Moores law needn't require longer passwords... (3, Interesting)

sanermind (512885) | more than 9 years ago | (#9915534)

As computers get faster, simply use more difficult and time consuming algorithims to verify passwords. If you use a verification step that takes 256 times a long [even for the same old 6-character password], when computers get eight times faster, they are worse off then they were before in trying to brute-force the password.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...