Slashdot Mirror
Moving Beyond Passwords For Security
Naturalist writes with an excerpt from a New York Times story about the need for a more secure method for identification than the password-based system almost everyone currently uses. The article also discusses the weaknesses of the OpenID initiative to simplify the process.
"The solution urged by the experts is to abandon passwords -- and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties' authenticity, using digital keys that we, as users, have no need to see. ...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else's Web site. Nevertheless, every few months another brand-name company announces that it has become the newest OpenID signatory."
Although the password is still there, many OpenID providers are moving towards advanced multi-factor authentication. For example, when I (or anyone else) attempt to log in to my OpenID account, the account provider calls my cellular phone. I must answer the call and confirm (by pressing the # key) in order to log in. This means that in order for an intruder to gain access to my account, they must have my password and my mobile phone, and if anyone else tries to log in to my account the unexpected call will alert me to this fact. I also know that other OpenID providers support the hardware key popularized by PayPal that generates a one-time password for each login. Other OpenID providers (including mine) support authentication via SSL certificates. There's a whole range of alternative and multi-factor authentication schemes offered by today's OpenID providers, and over time more and more methods are being introduced. OpenID allows users to choose an authorization service based on the security that they offer rather than based on what website they want to log in to.
I might be stupid, but that's a risk we're going to have to take.
MyOpenID allows you to use a phone call to log in. When you try to login, they call, you, and you press hash, it logs you in. Free too.
-- Lattyware (www.lattyware.co.uk)
However, "something held" can be considerably more secure than "something known".
Either way, the point is that TFA represents OpenID as a reduction in security, when, in fact, it allows you to implement whatever security measures you want.
This is a common misconception -- that OpenID is simply single-sign-on in new clothes. It's actually an opportunity to give the user responsibility for their own security, and that's a powerful thing.
Don't thank God, thank a doctor!
All "something you have" systems rely on that something being hard to copy. The Mifare card is such a security token. Your car key is another one. The complexity of cloning security tokens varies. Proper smart card design can make cloning very hard. Smart cards are not just memory. They're small computers which enforce a protocol that never exposes the private key. To find the key and clone the card you would have to find a protocol flaw and/or often physically disassemble the chip and read the memory with a powerful microscope (see Mifare). But when done right, a "something you have" system has the advantage that it doesn't need to reveal the secret.
You could theoretically perform a public/private key cryptography protocol with something you know, but since most people can't do maths with very large numbers in their head, "something you know" protocols usually involve revealing the secret. Sometimes the secret is only revealed to a trusted system which then generates another secret that is entered into the untrusted system. One time password tokens are an example of this kind of system. They keep the master secret secure, but the individual transaction is still vulnerable.
You're right. It IS a password. And it doesn't matter.
The PIN is a password that unlocks the smart card. In order to authenticate with the remote server, you need both the PIN and the smart card.
It's called two factor authentication. There are essentially 3 types of authenticators:
1) What you know (a password)
2) What you have (a key or a smart card)
3) What you are (fingerprint or retina scan).
Most web sites use one factor authentication - their security depends only on what you know (your password).
The primary attack that's involved here is an attacker attempting to guess/steal your password to a remote site. All they need to know is your password and they're in. And they can take your authentication information and use it from any machine on the internet - thus they can sell your identity and make money from that.
With a smartcard/pin combination they need both the PIN (what you know) and the smartcard (what you have). The PIN is totally useless to the attacker unless they also have the smartcard.
Adding the second factor to the authentication system does move "beyond passwords".
Per http://en.wikipedia.org/wiki/Kerberos_(protocol), Kerberos is a symmetric key system which requires a trusted Key Distribution Center to also know the shared secret (a one-way hash of your password). The advantage is that a phisher (who doesn't have your secret) can't pry it out of you if . It does have the weaknesses common to symmetric encryption systems; KDC compromise, KDC unavailability, etc.
Public Key Infrastructure encrypts the transmissions with the public key of the destination entity instead of a shared symmetric key. Kerberos has extensions to work with PKI. In these, the KDC doesn't know your secret, but can recognize that you know it.
Operating Systems will have a secure storage intended to keep your private key from being slurped by a trojan. PKI hardware tokens improve on that by moving the private key into a separate device, with its own single-purpose operating system (which is easier to certify, as long as you stick with well-vetted algorithms instead of http://yro.slashdot.org/article.pl?sid=08/08/09/1812256). The private key never leaves the token; all operations requiring it are done inside the token. To crack this requires two separate cracks; physically obtaining the token, plus phishing, sniffing, or torturing the corresponding PIN from the token owner.
So you can pick how much security you want, and how much you want to pay for it. It helps to make both decisions at the same time.
Sure, all I see are stars.
yes, it's a classic. http://www.bash.org/?244321
The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP.
Exactly, why to expose your own code to all the automatic probes that go around the internet when you could use "well-tested" webserver code instead? If there are problems with webserver authentication code somebody might patch it but if it's your own code nobody but you will be auditing it.
Sure, your authenticated users could still exploit your code once authenticated but that would at least limit the number of attempts.
It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).
It's worth noting that HTTP Basic Authentication just base64 encodes the passwords but doesn't encrypt them. HTTP Digest Access hashes the passwords but is vulnerable to Man-in-the-middle attacks so you need to use HTTPS anyway.
-- Reality checks don't bounce.
I work for an agency under DoD and have had what they call a Common Access Card (CAC) for more than three years.
Leaving my CAC at home has never happened to me but I imagine the experience would be fairly uncomfortable as the CAC is also used for building access - someone would have to sign me into the facility if I forgot my smartcard. I don't imagine I'd have to be embarrassed that way more than eight or ten times for it to sink in that I need to keep my smartcard with me ;-)
Humans (at least most adult humans) are conditioned to carry their driver's license with them when they operate a vehicle so learning to carry a smartcard with you wouldn't be all that difficult. To address the issue of requiring a keyboard and display (and a smartcard reader) there are contactless smartcards available and I *think* the technology's compact enough to include in a cell phone or other device.
IM frequently less than HO physical security will always be paramount - a physical token requires a user to have both the token and the PIN to that token to access a protected resource. In this agency there have been a few misplaced smartcards but there hasn't been one instance of a protected resource compromised because a bad guy had both the user's CAC and the PIN to it.
People tend to write down "what they know" if it's fairly complex - which compromises physical security. All I have to remember is an eight character PIN. My PC will lock my CAC after three unsuccessful PIN entries, which requires me to visit the card issuer to have my PIN reset.
All in all it's been fairly secure and easy to use. The transition to smartcards hasn't been completely painless but these days I use the card for building access (I have access to the raised floor area in the basement), to the network (smartcard authentication to the network is mandatory), to secure websites hosted on the network that use CAC authentication and to government-only applications that ping your smartcard to see if you're supposed to be running that application.
All in all it's been a pretty good thing and I was originally one of the naysayers on the project.
we see things not as as they are, but as we are.
-- anais nin