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.)"
password1 password2 password3 password4 based on the month that you are in.
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.
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?
Uselessful technology (Air-Charged
One day we'll have Biometrics, so we won't have to remember our passwords.
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
if moores law continues you should probably have to change your password every twenty to thirty seconds
SecurID and its like are your friends.
While you maintain a reasonably secure password you're not logging in without the token.
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.
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.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
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
How about a password that you don't know and changes every 60 seconds?
Speak truth to power.
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.
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
if you see me, smile and say hello.
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.
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.
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.
Processing power increases linearly, adding characters to your password increases complexity geometrically
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.
Beware: In C++, your friends can see your privates!
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.
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.
Do really dense people warp space more than others?
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.
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.
www.kitchengeek.com -- Nosh for
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?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
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).
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
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
typing
kGNisksUI725K-{P#~iuiILl896&Tui@'p;p'HH
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
http://slashdot.org/~GuyFawkes/journal
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...
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.
Two wrongs don't make a right, but three lefts do.
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.
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)
T = N/(PG)
In this:
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.
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
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
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.
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 the concept of storing a large key on your thumbdrive, which you then need to plug in in order to log into your machine.
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.
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.
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.
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
creation science book
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.
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.
Laboratree - Scientific collaboration based on OpenSocial.
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
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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.
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
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
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Windows XPs new password policy manager: "Im sorry, that password has already been taken by user john, please choose another"
This comment does not represent the views or opinions of the user.
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.
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.
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).
WARNING: there is a trojan on your
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.
Luckily I have Gator for remembering all my passwords!
Note to self: get smarter troll to guard door.
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 on how to do this with FreeBSD.
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.
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.
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.
I would use the crypto ibutton as an authentication scheme, possibl storing the password.
Religion is a gateway psychosis. -- Dave Foley
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
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?
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.
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
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.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
loop-AES uses iterations of MD5 to generete the final encryption password. On my config i hash my passphrase 1 000 000 times. Which makes the delay significant.
When will folks realize this? I can easily remember a password that is meaningful to me, even if it may be a word in the dictionary. When passwords are required to have 8+ characters with at least one non-alphanumeric, and change every 30-90 days, I (like everyone else) has to resort to writing them down. As a consequence, it is a lot simpler for someone to find the password and break into the computer system. Sure, they can't be as easily "hacked", but I bet casual theft of passwords and data by employees and people in the building is a bigger problem than someone trying to break into our fairly dull servers from the outside.
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.
Nice idea but not very well thought through.. The problem with this is the time to break only scales linearly. If I want to make the hash take twice as long to break then the algorithm has to be twice as slow. Contrast this to adding a bit to the hash length. I can keep the hash roughly the same speed but double the time to crack.
Also, another bit of food for thought. How on earth would such a slow algorithm scale. Imagine a POP3 server with 20 new sessions per second. It'd take a second to verify each connections POP session!
There's a reason why these hashes are designed fast. There designed to incur the smallest possible penalty for legitimate users but really bludgeon the crackers. The best way to make everyone happy is to use a longer bit length.
Simon
Depending on the type of connection, this could also make it easier for system admins to tell when someone is trying such an attack.
For example, if someone has had a connection open for a minute or two and they haven't managed to enter a proper password then it would be worth checking out. Of course this is true now, but with the quick hashing algorithms you can run through many more hashes then you could with a slower algorithm (or even a fast algorithm with a delay built-in).
Yes, they may take a little longer to type, but they are virtually uncrackable and if people would settle on an authentication method, wouldn't have to be typed very often. A passphrase as simple as "I love my children" is unbelievably hard to break compared to l0vch1ldn. Most modern systems are capable of very long "passwords" which we should start calling "pass phrases" and move the expiration time up to 3-6 months. As long as you are not passing them in the clear or writing them down, which is alot easier when you are using a phrase, there isn't much chance of it being compromised.
There are safe, secure, fast, automatic workarounds for forcing meat to type a password. IBM uses something like this in laptops that "self destruct" if an encryption chip is removed or destroyed. Such systems generate standard passwords at a level of complexity human beings are loathe to commit to memory. There is still a "secret" -- usually a large block of truly random memory stored in a dongle or USB flashcard -- and the algorithms are public, well-understood and unencumbered by IP restrictions. So why moan about being forced to change secure passwords once a quarter, when you can change them once an hour? Or as needed, for that matter?
has anyone thought of comparing the current use to statistical past use? for example, as i sit here typing on my workstation, there are certain keyboard commands i consistently use. there are certain words i consistently misspell, and even how i fix the mistakes. do i backspace all the way? do i highlight the typo, delete, then correct, or do i highlight and correct. there are many nuances that could be tracked, which might include simple thigns like using an application to open a file vs. using a file system browser (i prefer the latter).
;)
tracking this sort of statistical information could be useful in verifying that the current user is who they should be. there is no password to remember or forget. after the computer is statistically "sure" that the user isn't who it should be, there are several steps that could be taken. one of such would be to simply notify an admin. another would be to immediately lock the user out. or, what i think is the best idea - offer a challange question: "What month were you born in?" If they cannot answer the question correctly with a fair amount of rapidness, lock them out.
I think this sort of toll could be the ubercool way to ensure the user is who they say they are. Of course the possible downsides to this is not being able to have someone login and check something for you (maybe a good thing?)
Has this been tried, developed, or thought of? If not, I call prior art on anyone who patents it
Biometrics is good, but you could still get past it (for some reason, I start thinking about Minority Report at this point).
IIRC, the best system consists of "something you know" (a password), "something you have" (a USB token or access card), and "something you are" (biometrics). I don't know how many systems have all three.
It seems likely to me that biometrics are the way to go. With all the passwords I now have to remember both at home and at work I have begun to care less and less about keeping my retina or fingerprint away from any computer storage systems that might be used to invade my privacy later. A fingerprint or retinal scan or even voice recognition to one-way hashing mechanism (for privacy protection) could be very effective when tied to an accounting and privilege management system. One person one password. An employee leaves you simply suspend their account and assign their priveliges to their replacement if needed. My last job that I left ended up with me emailing them about a dozen passwords to virtually their entire internal IT system and web presence (small company). Granted all of those passwords (aside from my own email account) had been written down and given to management but lets just say they never really paid any attention to things like that. Biometrics means never ever having to give passwords over email to old bosses after you leave your job.
Why not stop brute-forcing by only allowing a limited # of "guesses". Allow like 10 tries on the password, and if it doesn't work the computer would just lock out the user until an admin resets it?
a password like "Your Mom Likes 2 dance! But Why?!?!" (without quotes) is not only easy to remember, it's damn hard to crack. The problem with "tough" passwords is that people don't want to remember something like "adfh93#$" as their passwords.
"Your Mom Likes 2 dance! But Why?!?!" is a bit long if you're typing it more than 1 or 2 times a day, in cases where passwords actually matter, a sentence makes more sense than a random password.
The truth doesn't care what I think.
If the only way to test if a password is valid is to use it against a running system, and each running system will only allow one password attempt per second it doesn't matter what your computational power is - you're not getting the password. [and if you're not inside a secure network you should be using a smart-card or at least a certificate anyway].
Kerberos is a definite no-no outside of a secure network. It will send to anyone who asks a little package encrypted with the user's password - so when you decrypt the package you know the user's password. ... you can request this little package for ANY user - you just need access to the Kerberos port.
That is indeed a good idea. Making the password hashing algorithm more CPU expensive is called Key Stretching. It should be an standard practice for every OS IMO. "Logging in" will take 0.1 second instead of 0.01ms, which is no problem at all. You can easily make a brute force Password search 10,000x more expensive with this technique.
Moore's law dictates that passwords will weaken, with respect to brute force processing, by one bit every eighteen months.
The problem is that nobody that I know of uses a slow enough algorithm for password processing to make current passwords effective with respect to cracking.
Let's say people use completely random passwords (already unrealistic) with lower case letters (26 values), upper case letters (52 values), and digits (62 values). We'll be generous and round up to 64 values (maybe someone uses a period or a dollar sign or something). That's seven bits per character of the password.
So, if someone is using an eight-character password), and perfectly following all rules, and using a machine-generated password with things like tildes, backslashes, and right curly brackets, they have a fifty-six bit password.
The slowest hash that I know of that's generally used and approved by lots of cryptographers to not have known weaknesses and to avoid collisions is SHA-1.
You just have to SHA-1 eight bytes for each attempted password, in such a case.
For reference, I just downloaded sha_v1.b, and it can eat through, on my p4, using brute force, about 5% of the possible password space a minute for 26-value, 6-character passwords (and I doubt that this is as optimized as it could be -- hell, I didn't even compile with optimization on. 64^8/26^6 = 911170, so a perfectly random "strong" password is less than a million times as strong. Thus, by running for about one month on one hundred compromised machines, I am guaranteed to break any password.
The main current goal has been to avoid ever allowing the hashed passwords stored on a machine to leak. This way, we can establish methods for preventing an attacker from brute-forcing the system. For example, I can have a system only allow one password attempt on an account per three seconds or so, which pushes passwords back into the effetive range again.
May we never see th
At work, I changed my password to 20 characters recently. Just for fun mainly, but its secure. I got the art of typing it down, so I can type it real fast, thats the key. I mean a 64 char password is great, but if you type it so slowly that the guy next to you can write it down as you type, its no good.
snowulf.com
Use public key authentication and require key changes every few years. Unlike biometric data, the key is revokable and changeable.
Now you could use either passwords or biometric info as the passcode for the key. Either one is recordable and repeatable, but is insufficient to provide access in the absense of the key.
LedgerSMB: Open source Accounting/ERP
It seem to me that the ideal solution is public key cryptography. Maybe you carry around a simple usb device that stores your private key. To log into a computer, you plug it in, the computer sends a text string, the usb device replies with a digital signature for the text string. The computer validates the signature with the users public key and if it's good, the computer lets the user log on. (Does anyone manufacture such a device? It seems like it wouldn't be that hard to mass produce.)
Much simpler than biometrics, it can be used to log into untrusted machines, and no need to install clunky retina scanners on all my computers.
-jim
The algorithms used on password login (hashing) or on simmetric/asimmetric cryptography aren't polinomial (at least i hope, never checked =), so don't ever bother about Moore's law. Instead, be pretty worried if someone achive a breaktrough with factorization...
First of all, a strong hashing algorithm makes any password harder to brute force (because it takes more cpu cycles [and use one actually intended for hiding things... not one used for checking against corruption. That might seem obvious, but it apparently wasn't to the designers of WEP]). Secondly, keep in mind that your user will not be able to remember anything much long than 8 characters (though informing them of neat memory tricks helps). Also, before making that new password policy _think_ about probability and keyspace. One good example is a certain department of a certain university I attended. They required 6 character password length composed of numbers and letters. However, the policy also did not allow letters next to letters or numbers next to numbers (the actual policy was that they forbid more than two letter substrings of any word in a rather large dictionary... try find a two letter combination not used in english, french, romanized japanese and half a dozen other languages). As a result, all passwords in the department were between 6 and 8 letters long and either #l or l#. Add that to the common user's phobia of the shift key and you have quite a security problem.
====
Crudely Drawn Games
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
This is brilliantly insightful. Computing power and sensor technology are aproaching the capabilities of dogs (seek Kurzweil's book "Age of Spiritual Machines") -- If you want to make a security company today, reversinging the decision process of a dog would be a very good one that should pay off in the next decade.
Rotates passwords every 45 days, and it must be at least 6 characters, have both upper and lower case letters and either numbers or punctuation marks.
Its a real pain in the ass, but I understand why they do it.
No matter where you go... there you are.
I happened to remember this study which compares passphrases and random passwords.
I found it interesting that passphrases are just as secure as random passwords, and as easy to remember as dictionary based passwords.
A 10 character passphrase based password is very hard to brute force.
Not a problem, I just installed Gator on all my work computers. Now I know my 64 character password is completely safe!
The solution that I've been using for a few years now is to use passwords for local logins only. That is, the password is accepted only when it comes from the console or a directly-attached terminal; i.e., when the password is known to have been physically typed on a physical keyboard. This situation is immune to dictionary attacks by being limited to the speed a human (or, in the extreme, a robot) can type.
For remote logins I use ssh public key authentication exclusively. I set "PasswordAuthentication no" in my sshd_config files to enforce this. This presents no opportunity of a dictionary attack.
So, to summarise, I divide authentication situations into two classes. Firstly there is local authentication, where a human must directly authenticate emself. Limitations of human mental capabilities preclude using a public key technique, but security can be achieved by taking advantage of the hardware nature of the situation. Conversely there is remote authentication, where a human is not directly present and authentication imformation is conveyed by software. This situation is inherently open to attack by software, but security can be achieved by requiring software to perform the authentication, allowing a strong authentication technique to be used.
Match the defence to the threat.
Interesting - so silly requirements lke "changing your password every 60 days" will mean a visit to a plastic surgeon!
The author is complaining about 90 days and 8 characters. At work, we are required to change our password every 30 days, and it must be 10 characters and contain three of the following groups: uppercase letters, lowercase letters, numbers, and symbols. new passwords can't contain anything used in the old password, etc.
Mechanically authenticating is definitely on the way out; there are much better ways coming.
Also, brute forcing can be made impossible enough by not making public the password hashes (those are rarely public nowadays).
Brute forcing right into an online service (password testing) is so slow (and should be stopped by the service after a few attempts) that I'd guess that six character passwords are plenty in that respect.
If we really can't live without public password hashes, maybe we'll just add another letter to the password every... three years or so?
We should stick to 8 characters with strong goodness checking until we got the better stuff going. Mandatory password change is bad for said reasons... it would even be much safer to have a sysadmin manually approve new passwords to weed out anything that the automated checks doesn't catch as too easy, and not force a good password to be changed.
There are better ways to battle leaked passwords, like always presenting to the user from where they last accessed the service.
Actually yes, Dallas semiconductors have been making it for years now. Have a look at their line of iButtons. They can even be fitted to a ring, or you can attach it to your wristwatch, or just use a keyfob.
Use it to sign onto windows, access control and whatever you think of.
I played around a little with a few cheap unique-id-only ibuttons and they are quite cool.
Harald
Just some summary of the solutions so far:
Limit login attempts: Usually cheap and easy to implement. However it does not protect from a case where a person gets the password file.
Computationally expensive hashes: If the password file is compromised, forces the attacker to spend more resources on an attack.
Two-factor authentication: The good news is that the attacker must have both the token and password to log in. The bad news is that the user must have both the token and password to login. Can be expensive.
Certificates: Can be used to decentralize the password problem. The server never needs to know what passwords the private keys are encrypted with. The bad news is that it takes only one compromised private key with a weak password.
One Time Passwords: Good against snooping attacks. Current software choices are irritating though.
I know of several companies that use sycronised password generators. You have a gizmo that changes its seed number every 6 minutes, you login, get a number to enter into your gizmo and it generates a responce number. no more password: password
There was an unknown error in the submission.
I just concatenate multiple (random) passwords.
In the past I had the "randomized" (generated) passwords for each account and while using it for a long periond I got to memorize them, and now I link two passwords into one long password, every time change the order and put a different sign between the passwords.
The SecurID systems I've encountered won't accept a login with the same number twice. Still, there might be a problem where someone hijacks your connection, but you've got bigger problems at that point.
i spend my life shredding little pieces of paper taped to monitors that say: username: jsmith password: pa$$w0rd
for those users that put a fraction of a second of thought into it, you'll find the little piece of paper taped to the bottom of thier mousepad.
--------- unix, because rebooting is for adding new hardware.
Lotus Domino uses a security 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 affective in blocking brute force attacks...
Generally, any system would be better with Notes security in place. It's certainly sufficient for several TLA orgs (NSA, CIA...)
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
Whenever you think of security, just think of the scene in The Terminator when Der Gubernator rips out the steering column of a car to use it. John Connor just flips down the visor, and the keys fall into his lap. "Are we learning yet?"
When you look at the state of the world, how can you not become a radical, liberal anarchist?
I just write the MD5 of my password on a piece of paper. When the time comes that I need to enter my password, I simply decode it!
MOUNT TAPE U1439 ON B3, NO RING
There was a law passed recently (went into effect on Jan 2004) in Italy that systems that are used by Italian citizens to have a 90 day password and a min length of 8 characters.
0 30925
You can find the link to the law here
http://www.garanteprivacy.it/garante/doc.jsp?ID=1
You will have to open the PDF, and then do a search on passwords.
Carter's Law :- "People are just as dumb as they ever were."
When Moore's Law crosses Carter's Law, Fun Fun Fun.
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.
The McCorp that I work for requires us to have a different alphanumeric password for each different machine we long into AND it expires every 30 days. Management says it is for "security" purposes due to the PATRIOT Act. (I work for a financial firm.) So I just end up using the names of beers I like to drink along with "69" for the numeric part. As long as I remember which "beer of the month" it is, I don't need to write down my passwords unlike my other co-workers. I just slide over their keyboards and voila, a list of passwords for each machine we log into. :-)
MIT got ahead of themselves a while ago it would seem...
http://support.microsoft.com/?kbid=276304
God, I'd hate to be the guy who had to deal with that one.
-Alex
Where to begin?
First off, the root password for the main application server is a straight alpha password that hasnt changed in about 5 years and is known by most of the operators and developers.
Second, there are trust relationships between most of the hardware in the company such that gaining root on one server effectively grants root on all of them.
Thirdly, many of the important infrastructure pieces (routers and stuff) have been given identical admin passwords that are well known (this was at least recently changed for the routers).
Fourth, much of the software we use to perform infrastructure functions is hopefully out of date, such that there are many published root level vulnerabilities for nearly every service running on our network.
And we are a medical device company under FDA regulation. No audit has ever turned up a single discrepency. How's that for reassuring?
Authentication based on something you know (password) is weak. You should use strong authentication (something you own, or something you are) by now on every system possible.
Contrast this to adding a bit to the hash length. I can keep the hash roughly the same speed but double the time to crack.
Really? When you're brute-forcing a password, usually what you're doing is this (simplified but it's the basic idea):
So I don't see how increasing the hash length can be more secure, if computing that longer hash takes the same time as a shorter hash. When cracking passwords you are doing exactly the same operation as when the login program is legitimately checking against the password database.
Yes, you can increase the length of the password, and yes, that will make brute-forcing take longer because the cracker has to test more possible passwords, but you try to get users to remember a very long passphrase exactly. But this is the point of this article, we need alternatives to this. Users will end up writing their password down somewhere if it's long and.. poof... there goes any semblance of security.
So unfortunately the only way to make it more secure is to increase the complexity of the hash algorithm, which as you rightly say has knock-on effects.
Imagine a POP3 server with 20 new sessions per second. It'd take a second to verify each connections POP session!
Increases in computing power will eventually make that moot, although as that happens the hashing algorithm becomes less secure again, and we're back to square 1. :(
I use this system to generate passwords. They are easy to remember, but still complex.
So with this song: "Mary had a little lamb her fleece was white as snow, and everywhere that Mary went her lamb was sure to go". We get: Mh4llhfww4543tMwhlw5tg. Not too shabby.
Of course, until your learn it better, you might get some strange looks around the office if you break into song everytime you have to log in.
The bad news is that brute-forcing passwords is a problem that is trivially parallelizable and therefore you don't really get 9 years. You get as long as it takes for someone to tie together 64 times more contemporary computers, which is getting easier and easier. Just imagine how many passwords seti@home could crack...
Disclaimer: I work for a company, but I don't speak for them.
Is a one time password is the same as a one time pad, or not?
do people still consider passwords reasonable security measures? how 1980's. use ssh keys. use SecureID. use netkey challenge/response systems. s/key passcodes. but if you're going to rely on any one component, for everyone's sake, don't just use passwords.
any real security system should be composed of (at least) two-factor authentication: something you know and something you have. encrypted ssh keys are an ideal example of this, as are SecureID physical tokens used with a pin. you have to possess a physical key, and you have to know some pin. you protect both, of course, but your pin or passphrase can now be something reasonable and easy to remember, as you're not trying to force the entire security system onto it.
granted, today, we still use passwords in lots of places. but the question for "the future" isn't "what are our passwords going to look like", but "what are we going to replace them with". let's try to solve the problems rather than just hacking on extensions.
i speak for myself and those who like what i say.
AC comments are usually ignored, because AC comments are usually pointless. So why should a moderator pour through AC comments in order to unearth the few gems, after all they are not paid to do so. This may be unfair but it is not unknown. I would suggest ACs use an account when they wish to post.
Woe be on to them, all who rise against poor people, shall perish in a the end. Buju Banton
For the university login, there was password expiray, by the time I had forgotten my 3rd password, my password became purple, it used to be things like ih43mimg (I have 43 moles in my garden) but I got sick of replacing my password, so they got the colors of the rainbow :)
:)
For my own server, the password is only used for sudo/su everything else is done though SSH keys, though I'd really like to have a smart-card which would only agreed to partake in a authentication process if it could preform the queiries for a iris scan
http://www.computerworld.co.nz/news.nsf/0/13684D9D 4D9F73ABCC256EA50068857E?OpenDocument
"An average end user had five to 10 different log-on IDs and passwords, and they wrote them down on little pieces of paper and stuck them under their mouse pads [or] under keyboards," Otto says. "They hid them everywhere because they couldn't remember them. That was a big security issue."
In addition, calls to the helpdesk by end users who had forgotten their passwords were costing the USPS millions of dollars per year in operating costs, according to Otto.
Looks like this time economics is on the people's side, not on a security paranoids' one...
The reality of the situation is, most users don't look at security the same way that admins do. When security becomes enough of an inconvenience, they dont care about it anymore.
Sure, technically they're supposed to care -- and they'll go through the motions... but they're primarily interested in doing their job (just like you are).
If an attacker is already in a position to start brute forcing your password files, you've already had a security failure. Passwords that are 8 characters in length are supposedly more secure - but typically a user will try to use a dictionary word, or a word that is familiar to them.
Using a combination of SecureID keychains with user passwords is, IMHO, a much better alternative than being draconian about password policies and asking them to pick an 18 digit password with letters, numbers, and symbols. While consulting, I've seen people become overwhelmed at their standard company policy, and (I'm SO not making this up) put their password on a sticky note, and place it on their monitor.
Teaching users how to think up a better password is always a good idea. For example:
My son Billy was on the honor roll this year.
The first letter taken from each word in that sentence would be: "MsBwothrty"
It's not flawless, but it's much better than "Butterfly" or something similar in the dictionary. Couple that with SecureID keychains or something similar, and you're less likely to have users try to circumvent.
I think the standard future of authentication will be multi-layered methods, instead of "one complex entry point" such as long or complicated passwords.
I was told that I could listen to the radio at a reasonable volume from nine to eleven...
I generally pick an easy to remember word of 8 or more letters and shift up a row on the keyboard. For example if my word is slashdot (easy to remember) my password would be woqwye95
Doing it this way ensures that I dont even know what my real password is. It is very random and IMO secure.
Keyring for Palm OS is a program that allows you to store passwords securely on a Palm OS handheld. It is released under the GPL.
The program can also generate passwords.
Show me on the doll where his noodly appendage touched you.
Cleaner
Advanced users are users too!
You work with idiots. Seriously, they are the kind of people who get executed in Texas.
D 4D9F73ABCC256EA50068857E?OpenDocument
http://www.computerworld.co.nz/news.nsf/0/13684D9
In addition, calls to the helpdesk by end users who had forgotten their passwords were costing the USPS millions of dollars per year in operating costs.
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.
Just use the Diceware method:
:)
http://world.std.com/~reinhold/diceware.html
Or just come up with a very silly sentence, like "The spotted sloths did't appreciate my apple pancakes."
Much easier to remember than even 6 random characters, and your mind will often generate an image to go along with something like this. If you mind makes an image for it, it's stuck for a while. In short, use passphrases rather than passwords. The keyspace for a passphrase that size is attrocious, even under dictionary attack. That's 54 characters! Throw in an ASCII picture of the sloth if you're paranoid.
Hopefully, your password hashes are properly hidden, and you are using something like MD5.
If the answer is you are using crypt(3), and the hashes are user visible, they you are in trouble. Crypt(3) is dead, as far as I am concerned. It only allows up to 8 character passwords, and is far too vulnerable to cracking on modern hardware. I wrote a paper for class back in 1997 on brute forcing crypt(3) using easily available software. Since I wrote that paper, cracking speeds have increased over 50-fold. Given a dozen 3GHz P4's (say a small computer lab), I can brute force all possible lowercase alphanumeric passwords in a little over 4 days. Mixed case would take longer, a week for 7 character and under passwords, and a bit less than a year for 8 character passwords. If I had access to a cluster, or a group of 0wned machines, it could still be done in a reasonable timeframe.
If the answer is you are using old-style NT LanMan passwords that someone can get a copy of, you are screwed. They use no salt, are uppercase only, and the entire keyspace can be brute forced like butter. The password is split into two 7 character halves, which can be cracked independently. If you have a machine running Samba, you can find these in the smbpasswd file. On NT/2000, they are still used if you have Windows 95/98 clients on your network. You have to extract them from the SAM using PWDUMP or the like.
If anyone wants to try cracking his or her own password, I suggest getting John the Ripper.
I always thought 1 year or 6 months were a good time for resetting passwords if the password is encrypted during transit. If the password isn't encrypted during transit, then it doesn't matter if its 1 day for password changes, it can be sniffed and reused immediately. As long as the password system does a time lockout after 5 failed attempts. So a brute force guesssing can't be used on the password system.
WhatMeWorry!
Use visual passwords rather than mnemonic ones. My standard-prescribed solution is to teach this to all new users; I set them next to a computer and give them some strips of coloured paper (not necessary but helpful with complete newbs). They'll get the gist fast and be able to be pretty savvy shortly -and changing a password is exceedingly easy.
Here's a visualization for the letter A starting from the key V:The plain password is: vgy7ujmh
Using alternate shift: VgY7UjMh or vGy&uJmH
This can easily be expanded to even more secure ones by adding more letters. A good scheme for variant passwords is to use something that identifies with the realm -for example for Slashdot, a password could be made from letters 'slash' (on a dvorak here, sorry):
qJkU.#4%kUp$xBjUy^fDbIxBmHf^7*xIy%mHg&f
Variation made easy. Try it.
Marxist evolution is just N generations away!
I've worked in some places in my time with passwords which were actually fiendishly difficult to even come up with in the first place. You know the sort of thing - nothing under eight characters, must contain at least one capital letter, one punctuation mark and one digit, no more than two of the same character in the string, no consecutive sequences of this, that and the other thing... It can take dozens of attempts to come up with it.
The boffins will tell you that this is so that you come up with a password that's harder to crack because it doesn't contain dictionary words or common number sequences or whatever. But surely when you're coming up with such restrictive rules on how to come up with a password, all you're doing is constraining the size of the set of all possible passwords, thus making a brute-force attack much easier? I mean, if I'm a cracker and I know that there's absolutely no point searching for anything less than eight digits, or all lower case, or all upper case, or all alphabetic characters, or anything in the dictionary, I'm off to a flyer, am I not?
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"
You sound like a user whining about changing passwords every time their current password has expired. I'd love to kick you in the nuts and tell you to shut up and stop whining. Your company just changed its security policy requiring you to change your password every 80 days instead of 180! Hey buddy I've been on a 45 day policy since... forever! The systems at my company have different password length requirements because they're on many different platforms. We got no choice but to remember which is which and that's the way it is. And what does Moore's law have to do with passwords? Are you trying to say that some supercomputer is going to be used to crack passwords? You don't need a supercomputer to do that. As long as there are dumb users, there will be a way for even the slightly intelligent hacker/ social engineer to get in to secure systems. The most stringent security policy is no protection when users write down their passwords, download spyware, open attachments from people they don't know, or even bother to lock their pc when they walk away. It is ridiculous of you to imagine that in some bleak, totalitarian, computer futurescape we will need to change passwords every 8 hours and make it some sort of lengthy ASCII (why ASCII?) code just to satisfy some sort absurd 1984/Big Brother overlord security policy. If you are having issues changing your passwords every 90 days, then buddy you won't be SOL in the future, you were SOL years ago.
..are smarter methods and mechanisms. The problem with most authentication schemes is that they give information away. Cryptography protocols that are found to be lacking generally give away more information than the designer knew about. (This is for the same reason that security mechanism composition imply more secure mechanisms.) Honestly, I think Zero-Knowledge Proof protocols are really neat, and may help solve part of the problem.
Why not have a pgp processor storing a private-key in a non readable register?
Put the processor in a USB device and have some biometrics verification on the device.
First, most cracking of passwords is done offline after they've obtained your hash. To prevent someone who's guessing a password at an interactive logon, just lock the account after 3 bad attempts. Now force the user to contact the help desk and provide personal info (like socical security # along with some other stuff) to reset it.
http://psynch.com/docs/choosing-good-passwords.ht
http://psynch.com/docs/password-policy-guidelines
Even more general guidelines about authentication technologies, including passwords, expiration, intruder lockout, tokens, etc. are here:r actices.html
http://psynch.com/docs/password-management-best-p
It's a commercial site, but this content is pretty useful and not especially product focused.
The solution is to use an hash algorithm such as Expensive Key Schedule Blowfish. This allows variable cost in computing the hash such that the administrator can arbitrarily increase the difficulty of cracking his passwords without changing them.
ThisIsMyPassWordThereAreManyLikeItButThisOneIsMine ...
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
That seems like a really good idea. It will work really well, if you remember what you're doing. There's only one problem that I can forsee, and that has to do with the keyboard layout.
What do you do if you have to type in the same password (say, for a Webmail system) on both Dvorak and Qwerty systems, depending on where you happen to be at the moment? I use Dvorak at home, and change the keyboard to same when I'm away (if I can), but sometimes I have to deal with a Qwerty system.
I don't know about you, but I infrequently want to remember what the keycodes are in Dvorak when I'm away from my system (i.e., what would a given phrase look like typed by a Qwerty typist on a Dvorak keyboard?) I find that task rather hard. I can type in Dvorak if I don't think aboout what I'm doing. If I try to think about it, I mess up. Don't even ask me where "H" is on a dvorak keyboard. I have to try to type "H", and then look at a Qwerty keyboard to see where the letter is. You get the picture.
The point is, say I set up a pwd by your method using the Dvorak layout, because I'm signing in/changing pwd from home. Then I get to a computer whose layout I can't change, and I need to login. Okay, so I remember what letter I started from, and what letter-shapes my password was. Problem is, those letter-shapes don't correspond to the correct password on the keboard layout I'm forced to use! What would you recommend for that situation?
I may indeed start doing this, if I can figure out how to overcome the above problem. Incidentally, what do you do if the idiot code monkeys put a MAXIMUM password length that is too short for what you want to do?
Frodo Lives!!
> Lotus Domino uses a feature where as each attempt fails
Interestingly, our Domino servers were "upgraded" last week - so now, instead of having one password for Bloatus (one for Notes, one for Sametime, and one for Domino) I now have three - which it seems to have randomly selected from the last half-dozen or so passwords I've used. I wouldn't mention Lotus and passwords to anyone in our organization if I were you....
Not everything that can be measured matters; Not everything that matters can be measured.
I think that passwords are coming to an end. Something will have to change.
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.
Passwords come short in one aspect - they do not validate the identity of the person. If we are going to use the computer for even more aspects, such as voting, government contact etc. we will need more personalized ID-validation.
:)
/dev/random | uuencode -m -| head -n 2 | tail -n 1
Digital signatures are allright for just regular identification in e-mails etc. but they are still not as safe as using real biometric validation devices. Using a fingerprint, analyzing the iris patterns etc. is the only way to make the identification process reliable and safe enough to use the computer for very personal matters, and I think that we'll move towards using biometric validation within the next 10 years, hence rendering passwords useless.
Actually where I live there's a ferry company that has moved to biometric identification through fingerprints - just order a ticket online with a special registered card # and you will be charged as soon as you go on the ferry. However, the technology is still not mature enough for these purposes - it was initially believed that using a biometric system would enable the company to save some money on the people who were checking the tickets. Unfortunately the system is somewhat unstable, and about 1/10th of the people who's using this system can't get their fingerprint to be identified correctly by the system, hence they need to have just as many people working on helping people who have problems with the system. Ah, the irony
But right now, passwords are still the only realistic way to go - so here's a tip for creating alphanumeric passwords in GNU/Linux:
NO_CHARACTERS=9
head -c $NO_CHARACTERS
Visual memory is strong but with enough repetition one actually starts remembering the sequence (usually within 3-4 days of active use) -and besides, the keyboard is there as a cheat sheet. I know which key brings which character up on Dvorak (I touch-type) so I can just pick those letters out on a QWERTY. The other way around would be more cumbersome but I don't think anyone uses Dvorak as their secondary layout? It is, granted, harder if one has to switch between layouts but not too much so -and we of the obscure layout are a clear minority.
As far as a maximum password length (which, oddly enough, seems to be the prevalent presence) one just has to modify the string a bit: take only the first letter, only every other letter, no vowels, etc.
So my recommendation: take it slow. Put your fingers on the home row and find one character at a time.
Marxist evolution is just N generations away!
Why are we so obsessed with passwords. You can get much more security out of a passphrase. Preferably one that employs some punctuation. Plus they're easier to remember. Why then are we stuck with the idea of using a single word that's increasingly hard to remember. You can have more fun with them. For example:
:-) (Actually my boss at the moment is a nice guy).
"The quick brown fox jumped over my lazy boss!".
These posts express my own personal views, not those of my employer
Each time you log off you should get a new password.
The password could be the answer to a question. Makes it easier to remember and increases the character length. What's difficult is remembering a password you've only seen once. I say Adapt. Overcome. You wanna get paid? Stop drinking and smokin' dope.
If your old password remains active for 15 days you could probably use that time to remember the new password.
Stuff that matters.
Fingerprint scanners are foolable, but that's not the only problem. What if you cut your finger? Do you have to wait a week (or more) for it to heal to log in?
Not a sentence!
We're a company of about 100 people. Most people trust everyone else, and almost half of these people have been working here for over 10 years.
Last year, we tried to make everyone change their passwords. My then-boss had come from much larger companies, and insisted on frequently-changing passwords( forced to change every 3 months). It backfired. Almost everyone had little pieces of paper with the password on it stuck on the desk in the clear. Personally making someone choose and use a complex password is.... well... complex.
So we changed the rules a bit. The password cant include the users name, should try to make it complex, shouldnt write it down, and doesnt have to be 6 chars, or have to change every 6 months. In fact theres no expiry date.
So in the next forced change, they again started attaching sticky notes on the desk. In time, the stickies will disappear and passwords will work the way theyre supposed to.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
1) Kiosk security. If somebody is looking over your shoulder (physically or digitally) it really doesn't matter how secure your password is. A 64-character password is no more secure than an 8-character one is somebody is filming your typing or using a hardware/software keylogger. This is where password changes come in. Changing your password every few weeks (maybe using a rotation of a few passwords) seems to make some sense here, if you use your password often on suspect terminals. If, on the other hand, you are generally using your password in your hermetically sealed server room, it might not be all that important.
2) Brute-force, which is what this article seems more to be dealing with. This problem is EASILY solved in a way that is far, far, too often overlooked. Simply do what I've done on my own system: temporarily disable the account after three unsuccessful password attempts. Furthermore, log all login attempts and report the number of failed logins since last successful (gotomypc.com has done this very nicely).
There are all sorts of human (i.e., non-password strengthening) methods to improve security. What I've done (or, more acurately, have had my employees set up on high-security client systems), additionally, is made it so that the accounts can only be unlocked via a special account with limited privilages (mainly to reset this feature and to reset user passwords). This account is only enabled for local, physical access.
The system is pretty cumbersome to brute force.
Statistically speaking, there's a 99.998% chance that my IQ is higher than yours. Get over it.
That's what salt is for, not to mention you can hash the hash an unknown number of times
Alec Muffett, author of Crack, the password cracker has an ongoing project to document & educate why reusable passwords are bad.
Oh, and no, I'm not Alec, just a friend who happens to agree that they're well passed their use by date.
Just memorize the serial numbers for every droid/starship/weapon in the Star Wars universe and use those. Shit, many of us have them memorized already. When we run out of obscure pop-culture references we can just use the names of the girls who've turned us down through the years.
Electric Monkey Pants
I've quickly looked over a few post, most stupid joking. Some are right on the money in my opinion about frequently changing password policies being a bit self destructive. It's always funny to see a post-it on a monitor with
Sure it has a mix of case, numbers and symbols but the person had to write it down to remember. This is why I think biometric systems are going to gain more and more acceptance.
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.
I'm surprised that I haven't seen any mention of diceware yet.
Allows for strong passwords with high entropy, but easier to remember than traditional passwords. Well worth a look, IMHO
>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?"
If passwords are easy to change make sure your users DO NOT have to remember complex passwords. I wrote a tool that uses a blowfish encrypted master password. The tool stores users passwords relatively securely and encourages use of complex passwords by generating high quality passwords that the user can copy and paste to the aplication/web site.
Happy to share source code if anyone wants it.
-- Sig meltdown immine...
http://support.microsoft.com/?kbid=276304
Hehe, sounds like an implementation issue... you can sync or single-sign-on all three, even with your windows credentials. I'm authenticating our Domino users via Active Directory, which means one password for windows login AND Domino apps. If I wanted to use IIS, I could pass the windows creds transparently (no Domino password to type in).
Check out "Directory Assistance" and or "ADSync", for Domino and SameTime
"Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech."--Benjamin Franklin
Is it a bad idea to disallow all but console password entry and require, instead, ssh level 2 keys for access? Or some kind of biometeric or other PAM-able requirement inaddition to passwords?
-- @rjamestaylor on Ello
Why not just halt the account if you try to log on more than "X" amount of times with the wrong password? How can you brute force that? Also, why not a key => password pair. the key can be any word like "looser" and the password could be a standard pass. Cap letter, num, special char and over 8 char long. That would increase security by a lot, not only do they have to crack the password, they have to crack the password with the right key.
Mark
what are you going to use if you are designing your own password? Your social insuarnce number plus the name of your wife plus first born plus your DOB plus......
a combination of biometrics such as eye, infrared, or finger prints and weightscale under chair.
Oh, and when you need console access, well, just boot directory into /bin/sh, change the root password, reboot, fix the box, change the password back to something crazzy. [done] :)
I'm currently using a program written buy Keith Brown called Password minder. Runs off the .Net framework and auto-generates strong passwords. I copy and paste passwords never remembering a single one.
Full article here http://msdn.microsoft.com/msdnmag/issues/04/07/Sec urityBriefs/default.aspx
Cryto people - pls check it out and let me know if I'm better off writting pw's down on a sticky note.
Yeah, you've hit the nail on the head. I have to wonder, though it would be possible to build up a dictionary of all possible encrypted passwords. This can be done now, but it's not practical, because the amount of storage required is so large. However, someday when we have some kind of "atomic" hard drives, which are capable of storing zillions of times more data then current technology, maybe generating a massive lookup table might not be such a bad idea.
Passwords are expected to be complemented by biometric methods soon, since the recent political developments everywhere will result in widespread use of biometric passports and other methods of identification. Once everyone has become accustomed to this process, it'll be a natural step to use these methods for a little bit of extra security...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Who cares? If you've got a system that allows millions of attempts, you've got a fundamentally flawed system. If someone can get read access to your /etc/passwd file, you're fucked. Plain and simple.
By having a password policy requires two numeric digits, you've just simplified my job. By requiring a special character, you've done me another favor (if I know your rules - which are probably available to anyone who brings up the subject of "stupid password policies" at a bar.
When am I going to be able to get rid of all my passwords and just use an retina scan? That's what I'm looking forward to.
We used to have to change our password every month to a new 10 char (it remembered last 5). I used to just run this VB script:
YOURDOMAIN = domain 'need to change this
user = InputBox("Enter username")
pass = InputBox("Enter password")
Set ns = GetObject("WinNT:")
Set usr = ns.OpenDSObject("WinNT://" & YOURDOMAIN & "/" & user & ",user", user, pass, ADS_SECURE_AUTHENTICATION)
usr.ChangePassword pass, "qazwsxedc1"
usr.ChangePassword "qazwsxedc1", "plmoknijb2"
usr.ChangePassword "plmoknijb2", "owidcjdcd3"
usr.ChangePassword "owidcjdcd3", "iojcdswdo4"
usr.ChangePassword "iojcdswdo4", "vownmdicm5"
usr.ChangePassword "vownmdicm5", pass
MsgBox("Password Changed (not really)")
Change password to something ridiculous, then change it right back. If it remembers three last password, change it four times. If it remembers it for a time, make the password very easy to remeber. "01234567", "12345678", and "23456789". The harder they make it on the user, the more the user will use it less.
Have you read my journal today?
We have biometric systems now. I forsee that they will just keep getting better and better. Granted, the ones now can be fooled by some individuals fairly easily, but give it 2-4 years... when they include a temp sensor in the biometric pad to determine that the "thumb" belongs to a human, not a manequin. Or that the retina scans detect a PULSE behind those little tiny red lines... THEN you won't have to worry about your 256bit encrypted password of the hour.
Stone
I direct your attention to this project:
w xyz0123456789!@#$%^&*()-_+= " which claims to be able to crack 99.91% of passwords 1-14 characters in length in minutes.
http://www.antsight.com/zsl/rainbowcrack/
which offers a program, buildable to both Windows and Linux, and runable under both, to generate rainbow tables of common hashing algorithms, then use cryptanalysis techniques to break hashes.
This might not sound too interesting to you at first...but read on: It supports LM and NTLM hashes. And that's not all: For $120, you can get a set of 6 DVDs containing sorted rainbow tables of LM hashes for the character set "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv
(I am in the process of building a similar table for NTLM hashes, but it'll be until Longhorn is out until it's actually completed.)
Who you are can't be based on what you. and anybody else, can know.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Feed your password to md5sum and use the result as your password. Works for remote access and root passwords at least.
Note to mods...these 'In Soviet Russia' remarks are never, ever funny. Even if you remember a time
In Soviet Russia, time remembers you!
Do you or your partner snore? - Visit www.snoring.com.au
Moore's law has no influence on password requirements. It's this simple.
1) Whatever you are authenticating to has a sleep time between login attempts.
2) Whatever you are authenticating to can lock out after a prescribed number of failed attempts.
3) Your shadow file is inaccessible to the attacker.
It would seem to me that processing power would have no influence on this equation. There are other variables to constrain, but the basic rules regarding password authentication are unaffected. The only difference is the crypto used to protect the channel used to authenticate over, which obviously has nothing to do with the passwords themselves.
I don't believe getting rid of passwords (biometric) or standalone or in combination with frequency in password change cycle will solve or improve security greater by ration. Human DNA is varied and unique by only less than ~5% or ~25,000 genes by expressed sequence (correct me at will), and only 0.1% or ~3 million base pair is unique among Human. However it's highly unlikely that someone (identical twin exception) will have identical matching DNA with you. Also it should be noted that DNA fingerprinting is already in use by military to id remains of soliders.
Obviously our DNA sequence mapping technology isn't here to process DNA fingerprinting on the fly (within reasonable time, cost and implementation), but perhaps within 5 years of increasing computing power and complete map of human genome, an ID tag with PGP encrypted key from DNA unique sequence tag imprinted with long lasting invisible die (rub on the skin like fake tattoo for instance) could be one way to decrease the cost of personal id, registration, administration, security, nonstandard identification process and implementation, lost & stolen ID card or password.
"Don't let fools fool you. They are the clever ones."
Biometrics means NEVER being able to change your password.
I don't see how it fixes this problem.
The dilemma is between passwords that are easy to remember, and hence crack, or too hard to remember, resulting in them being written down.
An alternative solution is Password Safe, a well-regarded application that "allows you to have a different password for all the different programs and websites that you deal with, without actually having to remember all those usernames and passwords". The main version is for Windows, but Linux variants (as well as an older PocketPC version) are also available.
Full disclosure - I'm the project administrator.
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
Gimme a thumprint scanner.
I'm sick of having to keep track of my logins for six home machines, work workstation, nine work servers, about FORTY FREAKING WEBSITES, and the ten or twelve remote machines I have accounts on.
SSH dsa keys help, until you get the massively ANAL sysadmin that forces you to change your password. Apple's developer connection was THE WORST for this. They made you change your password at fixed intervals and kept a very LONG log of your OLD passwords... they wouldn't let you use variants on old passwords, they wouldn't let you recycle old passwords and they damned sure as shit wouldn't let you auto-login. I stopped bothering with ADC because, simply put, logging in was too much of a pain in the ass.
If computing as a whole goes to a simlar model, I'm going back to the fucking abacus. The abacus doesn't require that I log in and change my password to something completely different every three weeks.
If I get owned, it's my own freaking fault- force me to change my password and you've forced me out of using your service. Your server isn't the only login I have to remember and trying to force it to the front of my head is a waste of my time. Keep track of the IP and MAC I login from and get anal with me if it changes- I can understand that.
There's a vast gulf between Secure Enough and Fucking Annoying.
Use smartcards. Use fingerprints. Do not rely on passwords.
Doesn't anyone here use RSA SecurID or the like? With that you can get a password that changes every minute or so.
It works so that the user carries with him a small device (the shape of a credit card) that shows a changing 6 digit "random" number. Your password is that number appended to your secret pin-code.
The card and the server are synchronized so that the server knows which number the card is displaying.
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.
US ASCII has 64 commonly used characters. If you use only those, then you have (with password length 8 chars) 2^6^8 = 2^48 = 2,8*10^14 combinations (48bit secret key).
But what if passwords weren't US ASCII, but Unicode and you could use any character you like... Your password could be 8 letters of klingon or some chinese symbols... or a mix then you would get 2^16^8 = 2^128 = 3,4*10^38 combinations (128bit secret key) without growing the length of your password.
p.s. ok... so unicode does not have all 16bit worth of characters defined, but close enough. See also Unicode 4.0, which is 32bit.
A few years ago when I was in an organization that started using secureID, I just forwarded all my email out, so I can access it from outside.
The "SecureID" system would lock me out any time some software automatically retried login with the wrong password (usually because the 60 seconds limit was crossed and the password changed) and then I had to wait for the next time I am at the office to reenable it.
(Therer was nothing that needed this kind of security in my stuff. Employing this kind of security measure organization-wide instead of in the few places it was needed was a mistake IMO. When you need to protect something you put it in a safe, you don't build a fortress around you!)
If a system administrator is doing the things necessary to reasonable secure a system, passwords are almost irrelevant, up to a stupid password like "password". As long as users don't pick something that an attacker can pick out of thin air (or a dictionary attack), and as long as a sys admin is doing a reasonable job, passwords should not have to grow in length and frequency of change.
Just my 2 cents.
Don't become a regular here, you will become retarded. -- Yoda the Retard
I can understand changing password every 60 days. I can understand requirement for it to be 8 chars minimum. But there are sites that have the following rules:
Password must be 6 characters or longer.
Password must contain exactly 1 digit.
Password may not contain any special characters.
Password is case insensitive.
Password doesn't start with a digit.
FedEx site has such rules. About half of them are revealed to the user, the other half I arrived at empirically, trying to come up with a password the system would accept.
So I don't see how increasing the hash length can be more secure, if computing that longer hash takes the same time as a shorter hash. When cracking passwords you are doing exactly the same operation as when the login program is legitimately checking against the password database.
Think of a hash like a random looking pigeon-hole function; I can pass it an arbitrary length string and it'll decide which pigeon-hole to stuff it in. The number of pigeon-holes is determined by the length of the hash so if the algorithm has a hash length of 128-bits then it has 2^128 different pigeon holes.
The obvious way to break a password is to try and find a value that hashes to the same as that stored in the shaddow file. Naturally, A good strategy is to try loads of possible passwords against the hash because people pick lame pretty lame passwords so the chances of success by this method are very good. Okay, so what if you I don't pick a lame password? What is the maximum security this function can offer if I pick a random password?
Well there are only 2^128 different pigeon-holes and an infinitude of strings. This means that eventually two strings will be assigned to the same pigeon-hole. i.e. Two string will hash to the same value. The question is, how long will it take me to find a string that hashes to the same value as that stored in the shaddow file? On average 2^127 attempts!
By increasing the hash length by one bit we have doubled the number of pigeon-holes, so you now have to check an average of 2^128 different hash codes on average. That's doubled the time it takes to break the hash open! If we add another bit then it takes 4 times as long to break as the original construction and so on and so forth.
Simon.
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.
Perhaps the days of passwords are over and private keys will be use exclusively in the future? I know that I almost never type passwords any more. Although I guess the pass-phrases I use are liable to a similar attack, at least they are only 'stored' in the relative safeness of my private key.
I am laughing all the way to the patent office.
Your internet license should be taken away if you don't use one-time-pads for passwords.
There is a very simple way of avoiding Moore's law requirements for ever increasing password lengths. Put a delay between attempts on the server. If it takes a second to respond to each password attempt, it doesn't matter how many planets of computers you have linked up trying to crack the password, there will be a limit to how many attempts can be made in, say, a month. The suspicious logging in habits should be noticed by then...
It takes two to tango.
The password will (are?) not usable on the long-term due to various issue like the limited length, the durability and the application of password (every where without a logic). Cryptographic key used as identification and authentication means is often a better alternative (think about the SSH public-key authentication).
Robert Hensing (MS Security Response) has an interesting article on this in his newly-created blog. His basic assertion is that we should all forget password complexity and just go for something long but simple to type. The spacebar opens a whole new dimension in uncrackable passwords, apparently. Robert's blog is at http://blogs.msdn.com/robert_hensing/
With a french keyboard you can even have stronger password as you have direct access to 8-bits characters.
However users and administrators (for user pwd reset) have so much imagination that the most (only?) common visual password is azerty, while it could be &é"'(- using just the row above. Of course, one is easier on the phone.
Historically, keys have been used for one thing and one thing alone: to prevent the intrusion of an unauthorized party. A password is nothing more than a key which you keep in your head.
... Everyone has a USB pen drive now, somebody just needs to come up with a standard for security keyfiles and then the possessor of the key is the one who gets inside. Changing the lock would be easy too, as a good network administrator could just set a day for everyone to plug in their key in order to have their security data updated, or whatever.
Never in history has this EVER been the case, except in the situations like elite clubs that have a big metal door with the little window and the man who says "What's the password, jack?" And in situations like that, the bouncer probably knows you and remembering the password isn't *as* important.
Imagine if you needed a password to enter and start your car, and the manufacturer forced you to change that password every month. The idea is completely ludicrous and would never be accepted by society, which is why society (the masses) have such a problem with passwords--they get in the way.
The month just started. I bet somebody out there had a forced password change and forgot their new password and had to call down to IT and say "Guys, what is my new password?" and provide his name, address, Employee ID number, and so forth. He might lose 30 minutes, an hour, maybe two hours getting things straightened out depending on how tight security is and whether or not the security guy is in his office, etc.
Forgetting is one of the easiest things in the world to do. As a matter of fact, there is current research which states that the brain very actively forgets things (the dozens of cars you pass on the freeway, the color of every leaf on a tree, etc) because the sheer volume of information is so overwhelming. Filing away a very abstract and intangible string of random characters--that they don't associate with anything more than a one-second experience prior to being able to do their job--and then FORGETTING that string, is one of the easiest things a person could possibly do. There is no scent, sound, sight, or anything to prompt its rememberance, it's simply an abstract and cryptic jumble of letters and numbers that you have to remember or you're fired. (well not always, but sometimes!)
The point is, "passwords" need to be replaced by "keys"
It's technologically feasible, it's already done in some places, but the current limiting factor is cost. If you didn't need to implement anything more than a software solution, then cost comes down to man-hours and man-hours comes down to: open source.
So get crackin', guys and girls.
Reinvent the wheel only at either a lower cost, greater effectiveness, or your own personal enrichment and satisfaction.
Who can make an analysis on the deviation of the Moore's law? Only then can we draw a conclusion about the password-length issue.
This leads me to the conclusion though that there are probably much fewer intuituve keyboard patterns then there are characters in the passwords. If someone created a dictionary based on keyboard patterns, I expect that it would be a significant way to overcome a lot of complex passwords.
The solution is easy by the time the computation power grows enough that this becomes serious enough to be a problem, you just build a series of challenge response phases into the process with shared secrets between client and server. By definition this process becomes an order of magnitude harder by just andding a single layer to the CR methodology. You need only have limited CR shared secrets (say 10) and reuse them in random order from login to login.
"The first thing to do when you find yourself in a hole is stop digging."
Two factor authentication as well as the more common use of passPHRASES rather than passwords will help tide us over in the long run. And once those are no longer useful, we'll have some sort of new method for authentication (biometric? GUI-based - entering a pattern or something?)
I think the question is answered before it is asked, and is completely self-evident.
Yes, passwords will become a thing of the past - in the future. Until that happens, I think we needn't worry, panic, and speculate.
I can log on as anyone at my company without knowing their passwords, by logging on as root and then using su.
Of course. But there is traces in logs (that you can alter as you are root), so we can not strictly consider that is the same.
Just dealing with the problem of users and long passwords:
r eshold=1&mode=nested&commentsort=0&op=Change
.. Yes, the problem is still there but it is harder to achieve
The problem of the user finding a long enough password is not hard..
For example, one could use a URL
The one at the webpage I am currently at happens to be:
http://ask.slashdot.org/comments.pl?sid=117247&th
The hard part is remembering it.
What if a system:
1) asks a user to type in just the domain name for the URL they select [in this case, ask.slashdot.org]
2) and then uses a search engine to come up with a multiple choice list consisting of 4 or 5 URLs from that domain and has the user pick one of them
IF the correct domain is used, the correct URL will be listed as one of the choices.
Problems:
A) badguy can figure out the domain by watching for a choice that re-occurs everytime that domain is used
B) The resource, or worse, the domain the URL is pointing to might be removed or no longer point to the same thing
C) user might not have an easy way of remembering what the full URL looks like and will find unsecure ways to remember
D) something I haven't even thought of
Are the problems really that bad?
A) Have the system allow a domain to be used only so many times by the users on the network
B) The system could pretend that it still exists and create URLs that look similar to the one chosen. This solution has some of the same problems as problem A, as well as the fact that badguy can go look up the URLs to see if they exist.
C) The user is not likely to write out a whole URL if the URL is long enough.. more likely, the user will write out the domain and some identifying mark from the URL. With a little patience, perhaps one can even train the user not to write down the domain name
I am just a fool. Please let me know how bad this idea really is.
P.S.
Ah.. Just thought of something else.. Have the server get and display random URLs when given a domain but then save that list and don't change them for awhile.. (I'd say don't change them at all, but then what if a user chooses a domain that badguy has already checked?)
My company's admin has set the passwords to expire every two month and the passwords have to have a length of at least 9, including 5 characters (from which one has to be upper case), 3 digits and a special character, like _*-... It gives you something like _Sdfgz456. Last but not least, the server keeps the last 10 passwords, so that you can only reverse to the first you used after 20 month. grrr...
Would it not be easier in that case for the government to dissolve the people and elect another? - Bertold Brecht
Smart cards are very easy to use. If you lose your card it's useless without the pin (and card can get locked out just like windows/linux if too many bad attempts are tried) and vice-versa, the pin is useless without the card. These enable you to not need rediculously huge passwords. Add to it a fingerprint scan and you have 3 factor login (something you have, something you know, something you are).
I love the idiot clueless IT types that think eight character passwords are the bomb. In the Microsoft world, seven is key. Less is less secure. More is no more secure. Seven shall be the number of the counting and the number of the counting shall be seven. Eight shalt thou not count, neither shalt thou count six, excepting that thou then proceedeth to seven. Nine is right out.
"Population 1,656"
I just log in as
User: rms
Password: rms
One thing I find iritating is the number of systems which I need a secure password for (and it's getting worse). And yet, only one of the 6-or-so systems I use at work each day actually needs to be secure, -(for privacy and anti-fraud reasons). The others only need the login and password to actually identify me, so if I annotate anything on the systems, or write a letter for instance, my name will populate a data-field somewhere. A 4-numeric PIN, with a 10-attempt lockout would be perfectly safe for that...
Check out this Knowledge Base article. Who sais MS products aren't secure?
For decades we have seen papers that prove that people do not pick passwords that resist computerized dictionary attacks. It is time to get over it, and stop expecting them to get it right. This is an engineering decision. You don't expect people to be able to lift a car to replace a flat tire, do you?
With a little training, and a few quick checks, you can get passwords from people that can't be guessed in 3--5 attempts. At that point, you lock the account, and are out of the password-guessing game, permanently. See? Even a random dictionary word is ok when used like this.
That means you have to get out of the oracle (little o) business. ssh-agent should not be able to tell if you have picked the wrong pass phrase.
I've been believing for a while that the current user id/password system is anquidated and insecure. I think user creditials need to be "query" based--meaning:
When you set up your account, you get an user id (of course). But then you set up a dozen or so of question/answer pairs, of which several will be asked of you when you sign in.
For example
userid = objwiz
question = what is my moms name?
answer = I dunno I was adopted
question = what is my favorite color?
answer = red no blue
question = what is my favorite food
answer = ask my gf
The point is that the question/answer pairs are information that is a) unique to the person creating them; b) dont require that be written down because the question in the way its worded should be your clue; c) is not very crackable via dictionary or alogrythim attack; etc....
Storage requirements for such a system isnt issue today. Even our phones have plenty of memory for something like that.
It seems to me the biggest reason we dont have anything like this is the momentum required to change an existing system.
Before we have to use 64 char passwd and change it every day, I guess other methods will come into play. For instance, a computer system may came with a touch pad that checks user fingerprint or other more subtle unique biological identities. :-)
Most system support locking an account down on 3 password attempts, and a delay between password attempts so what does it matter if a powerful computer can crack a password in a straight on attack? After 3 tries it will fail in its goal.
This all hype generated by the foolish an uneducated. The real issue is in encrypted files and communications not login passwords into systems.
I've been reading through this, wondering when someone who's been paying attention to recent password attacking research would post this. I've used the opensource rainbow tables stuff, and now @Stake is selling their latest version of L0phtCrack (renamed LC5 for political correctness purposes) with rainbow tables included. This technology does work as described.
Static passwords are no longer acceptable. Period. If you have a resource worth authenticating for, then strong auth (PKI, SecurID, one-time pads, etc.) should be manditory. If you can't, STOP USING UNENCRYPTED PROTOCOLS! It astounds me that companies that have bought in on firewalls, IDS, antivirus, SSL certs for web servers, etc. are still using telnet and FTP for critical business data! Saying that you can't sniff on a switch is a lie, just check out ettercap, which allows an attacker to poison ARP caches to force traffic to run through a system of the attackers choice.
BTW, IAACSA (I Am A Computer Security Analyst)
If i have ever wanted to aquire the use of someone elses computer i always go for passwords last, and that is the absolutely the last resort. Why i hear you ask, well i find that distracting and making people forget they are still logged onto their system works a hell of a lot better and is easier, also when those ideas dont work i find brute force extremely useful, and as my frend mark just said "haha yes, beating someone senseless whilst they're still logged on, is pretty unavoidable", sums it up pretty well i think.
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.
You mean those locking drawers where the key number is stamped on the lock?
I usually place a sticky note with a ramdom number of characters under my keyboard. It looks like a password, and may even BE someones password.
But it is not MY password and is it not close to my password. This entertains whoever is trying to break into my computer for hours....
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
The original comment was that an admin who actually knows your password can login without you, the user, knowing of said attempt. Regardless of knowing the users password or not, the admin is capable of doing this as he does have access to all the logs on the system and can feasibly remove necessary entries to cover his tracks. Any other person who doesn't have admin access won't be able to do so as he can't erase the logs.
I'm not going to worry too much about whether or not root can see my password as if he wants to screw me, I don't have much say in it.
Recent research supports the belief that one well chosen password will defeat most intruders and that enforced rotation leads to weak passwords.
Here in work i've implemented a reasonable level (read: what you get for free from MS) password policy on the GC/DC (its a MS shop).
Passwords:
* Vary between Upper and Lower case
* Contain at least 1 number
* Have a minimum of 8 characters (MacOS9 users are only allowed to use 8 unless they have the MSUAM)
* Forced change every 90 days
* Differ from the 3 passwords used previously
In addition we encourage users to pick strong passwords:
Good Passwords contain:
* Multiple small words (let me in now: LetM3In0w)
* Unusual keys (open at eight : 0pEn@Ate)
* Personal Acronyms (open now please : 0pN0Plez)
* Replace letters with numbers (close please : C7o53p7z)
* Misspelled or nonsense words (close please : klOz3PeaZ)
* Offset the Number/Word (to home sweet : H0m325we3t)
* Non-sequential words from songs/poems (home of the brave: 7hebRaFovH0m3)
* A combination of the above!
Bad Passwords contain:
* Countries or Place names
* Names (First or Last)
* Anything Workplace related
* Historical events and Dates
* Personal information: Phone numbers, Birthdays or Social Security numbers
* Dictionary (English and Foreign language) words
* Consecutive numbers
* Popular phrases separated by spaces, underscores or a hyphen
I recently conducted an audit using the excellent @stake LC5. I used the SAM agent import feature and not the sniff the wire capability. It cracked 26/196 passwords in less than 50 seconds with straight dictionary attacks tho' to be fair it was running checks against the weaker LM password. It finished the run with 96/196 successful cracks in around 11 hours using the dictionary, hybrid dictionary/brute force and straight brute force cracking.
It got many "strong passwords" chosen using the above methodology which is similar to the previous post. I am not too worried as ANY password is vulnerable to determined brute forcing. Thats the reason you combine strong passwords and an x-attempt lockout policy.
The bonehead central office still enforces the password rotation despite the evidence that users are sabotaging the process. I sincerely believe this collision of function and security is a zero sum game: the users need to work meeting a complex security process irrespective of the necessity.
I am actively looking into 3rd party DC/GC extensions which perform the routine checks LC5 used so successfully and that have been in use on *nix systems for years. I'd love to hear from any1 in a similar situation. Please note i had reservations purchasing from @stake based on their abhorrent treatment of Dan Geer and evidently vindictive successive OSX disclosure campaign.
Of course, if the device you make is as dumb as a dog, I'll bet a couple raw steaks that I can get it to like me, too.
If you just told people to think of a word. then insert a number after each letter. Starting at one point and counting up/down. And use alt caps. You have a very hard to crack password.
i.e
Word is Canberra.
Password: C5a6N7b8E9r0R1a0
It takes a fair time to think about it and type it out the first time. But each time you type it you get faster and faster. I found I could time is easy fast enough for no one to be able to work it out after 5 attempts.
I use a file encryption program called AxCrypt along with a USB key; works great, albeit slow. A built-in AES or Blowfish function in the OS would be even simpler.
Good idea or bad idea?
How about changing your keyboard regularly. As a consultant in the Benelux, I get type on different keyboards every 2 days...
;-)
btw, did you ever think that 'some' biometrics could be extremely annoying for some people
Mike
How about the obvious, limit the number of password attempts. If an IP address is locked out for 15 minutes after 5 attempts it doesn't really matter how long your password is.
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.
Recently the company gave me a laptop, and one of the conditions of getting it was, "ya gotta take it home"... So not only would an attacker need to know my password, he'd have to find it too...
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...
the one thing Lotus Domino did correctly...
never underestimate the bandwidth of a station wagon full of tapes
I don't know what you are talking about "where the key number is stamped on the lock." Are you saying it is common for locks on desk drawers to have numbers on the lock so you can send to the manufacturer or perhaps a locksmith to get a replacement? If so, the simple solution would be to replace the lock. Even if not replaced, you have the following advantages by not putting it on the monitor:
1) Password availability is not as obvious, especially to casual visitors or maintenance staff.
2) Two trips are necessary (one to get the key number, the next to come back with the key, assuming there are too many key permutations to carry with a person)
3) If the saboteur does just pry open the desk drawer, it is known immediately. Also, if you don't have good physical security, extra IT security won't make up for it.
I personally like the fake Post-It note method, if some mnemonic method doesn't work better. I like the dummy password, but I wouldn't think one dummy password would occupy a hacker more five or ten minutes.
Are you saying it is common for locks on desk drawers to have numbers on the lock so you can send to the manufacturer or perhaps a locksmith to get a replacement?
:-( For instance my 3 locked drawer/cabinet locks are all stamped with W426 as is my key (ok I lied about the ACTUAL number).
....
It is here
but I wouldn't think one dummy password would occupy a hacker more five or ten minutes.
But how many people try to obfuscate (sp?) the password by adding a few random chars in the written one, or maybe reversing it, or maybe using every second character,
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
he'd have to find it too...
:-))
Just don't leave it in the car when you visit the peeler bar on the way home
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
> you can sync or single-sign-on all three
... until last week.
Yep, that's what we used to have
"Do not meddle in the affairs of IS departments, for they are stupid and quick to screw things up..."
Not everything that can be measured matters; Not everything that matters can be measured.
All you've done is reduced the search space for a brute force crack. And now it's not even obscure--you've just posted it in the one place where almost every cracker is guaranteed to see it and someone will probably incorporate it into the next version of a cracking engine.
Better idea might be to issue a uniquely scrambled rectangle of letters to each user every N days (and a uniquely shaped overlay if practical).
Crypt passwords had several weaknesses. One of them is it took MUCH less time to compute a crypt hash versus an MD5 hash. Given this, you can simply make hashing algorythms computationally more expensive and that would mitigate the brute force/password problem. There still exists a number of other problems though, including:
.02
How to make sure usable/replayable credentials are not picked up while traveling over the network. This is STILL a big problem with many systems, especially legacy ones. We should be more concerned about this problem than forcing users to change their passwords every time they leave their chair....
Just my
You'll have a 128(256, 512, whatever big number you want) meg password program key that checks factors such as date and time to generate a working password to pass on to the computer in order to get in to your account, then you'll just be responsible to carry your password dongel around with your ID card that gets you through the doors.
This also has the advantage of stopping prople from using others dongels, since the dongel will HAVE to be in place to log in, and it will only get them into their account, rather then just an account. With a 128 meg password being generated from arbitrary data, it would take anything short of a quantum computer too long to crack the pattern, and you can change the pattern every month or so- and you don't have to remember a thing; your littel USB dongel handels it.
Another option is to have the usb dongel carry the data nessassary to get a window open (like if the server uses linux, the server checks for ALL of the bash/ssh/X files in the USB dongel directory, so that anyone attempting to access it remotely without the 'key' being in place meets with nothing but fustration, however services that started on bootup (when the dongel was in place) continue runing)
-Millions of Monkeys, Millions of typewriters, 6 hours of sorting through faeces encrusted pages to find: This post
Ultimately the issue boils down to the fact that the only person a computer is really safe from is a stupid one. And they possibly have to be dead too. Like in the classic game Scorched Earth - even a Moron would occasionally get the right angle and power to come under your mag deflector and waste you.
The company where I used to work assigned a [wait for it] _4_ letter password! How cool is that?
Oh, did I mention that the password was _the same as everyone elses?_ (So other people could log on to your workstation - part of it was a retail environment, so it was necessary, but I don't know why they didn't just set up roaming profiles... the place was a microsoft gold partner, after all - they had the facilities!
Founder & COO, Hayai India (hayai.in) / USA (hayaibroadband.com)
I get a half a dozen failed password attempts per day for the guest account on my home machine. This on an account that doesn't even have a password set! (the shell is however nologin) I've always wondered if I should try to track these requests down and report them attempted breaking and entering.
When the crackers are looking at the wrong account it doesn't matter what the password they try it.
Nope. You may be an ubergeek like the rest of us but the norm won't take too well to an assigned password, nor will they remember their own very well if it's nonsensical.
This is an introduction to generating strong, easy-to-remember passwords. Users will find this method, if not exciting, at least unintrusive and will quickly develop their own style -for example, in the second week of training, the last tally was that two people were drawing smiley faces, four writing upside down or backwards, two doing geometrical shapes and the rest an array of animal or hobby shapes, hearts etc. Only one person had stuck with 'traditional' lettering.
Any password can be cracked with brute force so that point is moot; in addition, this would hopefully deter social engineering as the user would have to think about how to explain their password to the requester instead of just blurting it out (thereby hopefully stumbling on that vague "Never give away your password to anyone" recollection from orientation).
Marxist evolution is just N generations away!
There are databases online that have stored all possible combinations of passwords as an MD5 or other hash. Just enter yours and within 30 seconds the password is found using a quite simple search algorithm instead of encrypting everything all over again and again and again.
/home and /var filesystems, and store the key on a USB memory stick for instance. Can be done, though I haven't gone that far myself either. I'm afraid the memory stick gets lost. :)
As computers get faster, these databses can be made and searched through faster. You gain nothing.
It's sometimes also possible to just use the encrypted hash for authentication. Since a lot of network protocols encrypt the password on the client and send it to the server which then simply compares the 2 encrypted passwords. So you don't need to actually know the password, the hash will do just fine.
To protect your data, don't rely on passwords alone. Try to encrypt your
So right now if someone would just open my computer and put the hard drive in his, (s)he can read all my files.
Similarly, I think it's quite easy to sniff a network for roaming profiles. Never tried that actually, but it would be fun to do
Ofcourse you can always look for zip disks and CDR's lying around...
...you can get hardware devices that do this now that sit in line with the keyboard (keyghost, et al)...you can even get keyboards with them already installed. as for software: if it's compromised, then no.
as ever, unless you built it, you can't trust it 100%. however, for the non-paranoid, a 99% level of confidence is probably enough.
VMS does something similar: it remembers when you enter a bad password, and after a few times it will lock from that terminal for a while. During that period, it would refuse access no matter what password you type. The lock-out period is randomized, so an attacker would have to guess when it was over.
Limiting the number of login attempts is not such a bad idea: if you don't remember your password, you give up after a few tries and call the admin. If someone tries to log in dozens of times, it's bound to be an attack.
If the account unlocks automatically after a while, the chances of a large-scale DOS are limited as well.
WWTTD?
Our SysAdmin would just try to crack everyone's password every few weeks. Anyone whose password got cracked got reprimanded.
Yes, but posting "First post!" around this point loses the charming innocence it usually has.
Yeah but posting "First post!" around this point seems to lose it its usual charming innocence.
After compromising a system the first thing most people do is obtain a list of the stored password hashes to start your disctionary attacks. Or, after installing network sniffers or keyloggers, depending on how ballsy you might be feeling that day.
So, the length of the password can matter, or at least at one point in time, it did.
..don't panic
... that sig just fit too well.
BIGstan!