Ask Slashdot: Convincing My Company To Stop Using Passwords?
gurps_npc writes Any password policy sufficiently complex to be secure is too complex to remember so people write them down. Worse, company policy is to leave a message on your answering machine describing it — when the software uses a 6 number password to get your 8 letter/symbol/number/capital/no dupes (ever) real password. I want to suggest a better method. I want to go with a two factor system — either token based or phone based (LaunchKey, Clef, Nok Nok). Does anyone have any advice on specific systems — or points I should bring up? Or alternatives such as graphical based passwords?
Your system will be breached. Do you get enough out of this to take the fall when that happens?
Have you considered how much it will cost your company to implement and manage such a solution?
You'll need to be able to convince management that the likelihood and impact of your company's IT infrastructure is high enough to justify such an expense.
Deal with reality - the world as it is - rather than ideality - the world as you would like it to be.
Anything you do that adds an additional step to an existing process they "appears" to be working perfectly fine will potentially earn you some enemies. Some of the people most likely to be frustrated by the process may also be in positions of great influence.
A noble cause, but its success depends a lot on the existing culture of your workplace.
Certainly coming to the table with a well thought out argument in favor of this isn't bad.
But if the culture is right, you should be able to bring this up casually with superiors and discuss it with them candidly and THEN discuss putting together a formal document proposing a solution. If anything they are better equipped than we are to evaluate the user needs of the workplace and give you ideas of how to pitch this to the rest of the business.
Figure out how much time and effort tech support spends on dealing with forgotten or compromised passwords.
Factor in the time lost by employees while they wait for tech support to deal with password problems.
Find some research discussing the cost of a compromise.
Figure out how much a token based system will cost. Assume people will lose their tokens.
Make the case that your solution is cheaper than the existing solution.
Then prepare to deal with "but we won't get compromised, so this is a waste of money"
[Fuck Beta]
o0t!
Just don't answer your voice mail.
You laugh, but I once advised a friend to write (most of) her passwords down on a slip of paper and carry it in her wallet.
Any policy has to take into account the circumstances and concerns of the user into account. In this case she was an author who was being cyberstalked buy someone who'd figured out her easy-to-guess password. She changed the password to her site and he promptly guessed that one too.
So my advice was this: generate a moderately tough password, say a ten digit random number, and write it down twice: once for her files, once to carry around in her wallet. Then add to that an easy-to-remember part, say the name of her best friend's cat, but don't write that part down, keep that in her head. This results in a password that looks like this: "491-265-4743Fluffy". I chose ten digits and formatted it that way because if it looks like a phone number pretty soon she won't have to carry the paper around. I reckon that this adds something like 32 bits of entropy to her weak but easy to remember password. Even if you know how the password is generated, it's not trivial to guess or break by brute force, and it's certainly not practical to guess for someone who doesn't have physical access to her wallet.
Is it secure enough for the Morgan Stanley family jewels or the nuclear launch codes of the United States? No. But it's good enough for most practical purposes where you're not that concerned about an adversary who has physical access to you.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
In that XKCD he doesn't treat characters independently. Instead, he assumes that each word provides 11 bits of entropy (i.e. assuming uniform draws from ~2000 words), giving a total of 44 bits. That's far less than the (26^20) you'd get if you treated the characters as independent random samples.