Slashdot Mirror
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?
Oh man, that's peanuts compared to my job. Our Cicso IP Phone VOICEMAIL has to be a 7 digit or longer password. And they block repeating numbers, obvious guesses like 867-5309 (or your own phone number). They block patterns like pressing the keypad diagonally or all the corners twice or whatever. AND you have to change it every 30 days. You better believe everyone keeps a post-it with their voicemail password right on their phone. It's a self-defeating system it's so complex.
As soon as you succeed with the paperless office, and don't forget to get rid of the fax machine too, then it'll be time for the password-less office. Just sayin'
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!
use u2f, its the best authentication token on the market. Either as second factor, or as lone factor. It doesn't enforce any lock-in at all, and its experience is just like keys: you have cheap tiny things you stick into holes (please spare me with any childish dick/buttplug/etc comparisons).
If they only need to survive online attacks, the 8 character limit is enough for Passwords. However you would need to add some meaningful brute-force and weak pw recognition.
The reason I wonder if 2FA can be at least moved to the edge or used for VPN logins is that it makes things a lot less of a headache.
Usually for internal AD, having a third party authentication apparatus strapped on can bring about issues. For example, if the system is a challenge/response system and a Web app is authenticating from AD, it likely won't have a window to present the 2FA challenge. SecurID is the only one I know which gets around this since there is no challenge token presented... users just enter in their password and the number off their token, and it logs them in with the standard username/password box. However, the downside of SecurID is that it is not cheap, and requires at least two servers to authenticate the tokens.
Internal logins, I'd just stick with AD unless there was really a need for internal security (expensive). If so, I'd then go with CAC/PIV tokens because they are fairly standard, have a wide use with the US government, and work with most major applications.
Now the edge is a completely different beast. You can set up RADIUS servers to use the Google Authenticator, SecurID, smart cards, or one's flavor of choice. This way, users can log in via 2FA, but the internal network doesn't need to have any major changes done to it.
What ever happens!! Do not start your proposal with "Let's stop using passwords."
Besides, in every system I've seen with 2-factor authentication, passwords could still be used, but 2-factor authentication would only get triggered if the employee was accessing the network from an unknown computer, or an unknown ip address, or if the employee had forgotten his original password.
Not to mention that stabbing yourself in the eye with a pencil will probably be less painful and result in more real security. And at least the eye-pencil is likely to make it to completion.
My favorite part is having to change the password every 30 days.
A LOT of people will use base password+date. EG:
Slashdotnov2014
Slashdot1114
etc.
Gee. I wonder what it might be in December...
I even know people in IT with passwords like that. When setting up a new computer for you they'll ask for your username/password so they can log in and setup your profile, so they are well aware that people do that.
I would encourage users to write down their password on a piece of paper.
That paper should contain only the password, no hint to what it belongs to.
The paper will then be stored inside the persons wallet, and looked at when neccessary, but not taken out.
If that person manages to loose their wallet, they have bigger problems than the company password.
There are no atheists when recovering from tape backup.
I used to work for an oil company that used smart cards to login to a PC.
Sure, you still need a PIN but you also need the card. It's not foolproof but it is somewhat more secure.
The real challenge would probably be convincing your company to purchase new hardware and update their security policy.
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
For the same reason the TSA acts the way they do. If you take security to insane extremes such that everyone is always massively inconvenienced, you can never be blamed for not doing enough, no matter what happens. And there's an implicit assumption that if you've moved onto crazy extreme measures, you must have already exhausted all the less extreme measures.
Complexity matters mainly if your attacker gains offline access to your hashes. Far and away the main source of password compromise is non-uniqueness (using the same password elsewhere). This is actually the main benefit of forcing a periodic password change. Graphical and gesture passwords are horribly insecure from shoulder surfers.
If you can, support as many factors as possible. Multiple factors gives your users flexibility- they may not always be able to receive an SMS or have a card reader handy. TPM-based virtual smart cards are super handy for remote auth from a domain-joined device- no cards or readers required.
So long, and thanks for all the Phish
My routine way of logging onto anything that I hit less than once a week is to automatically click on the "I forgot my password" button and reset via email without even attempting to remember it. That basically makes all passwords equivalent to my gmail password, but since anyone with the gmail could do that any time they wanted it's no loss of security. It's a little inconvenient, but not as inconvenient as trying to remember 100 unique passwords.
Write each new password on a separate post-it and keep them all posted around your desk. Let an intruder guess which one (if any) is the correct one! It will provide minutes of entertainment! MINUTES!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Very long passwords are very easy to remember if you use mnemonics.
For example:
412a7YaoFbfotCanNciladthptaMace
Completely impossible to remember that password right? Wrong:
""Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.""
You just have a set of rules for turning text into a password.
In this case, all numbers are written as numbers and all words are lower case except nouns which are capitalized.
Substitute that quote for any other and you can generate another very long password that is impossible to forget. You can even write the quote down prominently and no one is going to break into your system unless they know the system by which the quote is turned into a password. The system I cited above is very very simple but you can use a much more complicated one.
The system usually should not change. You can keep that static. The quotes or text strings should change every so often. And when you do, you can put a sticky note on your computer with the quote right there. No one will break in.
You can make the password as long or as short as you like.
The downside is that the decoding process does take a moment. But you will not forget the password.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
FIDO alliance 2-factor hardware tokens, like YubiKey Neo.
Until browsers roll out FIDO protocol support, a mobile app with normal OATH TOTP 2-factor (implementations include Authy, Duo Mobile, Google Authenticator, etc) is the way to go. And use a password manager for the 1st factor. When support gets baked in, the FIDO serviceclienthardware token protocol will dramatically improve usability of the 2nd factor.