Moving Beyond Passwords For Security 235
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."
Yes, we know. (Score:5, Insightful)
The solution is public key cryptography. The problem with that solution is that it only works as "something you have", not "something you know", which is the authentication mode of passwords. You can't leave "what you know" at home, but will you always have your smart card with you? Another problem is that secure public key cryptography requires a complete terminal under the control of the user, not just a card. The private key can never leave the user's control and the user must always know what it is used for. That requires a display and keyboard. Not something people want to have on them whenever they need to authenticate.
Re: (Score:2)
Why not send authentication query via SMS or standard phone lines? No keyboard required.
Re:Yes, we know. (Score:5, Insightful)
Yes, if you're always where there's phone coverage and you got battery. However, it doesn't solve the problem of a compromised terminal. That was what a bank virus did not that long ago, waited for the user to authenticate then sent money elsewhere "behind the scenes". Sure it might not get your email password but if it silently downloads your inbox compromising every password mail you ever got, well gee that's nice.
Re: (Score:3, Interesting)
It's an ineffective way of using your phone as "something you have".
I propose installing a program + private key on your cellphone, and use that to encrypt a random token. Then you get a hash of the ciphertext on the cellphone display, which you enter in order to login.
It could even be nicely integrated into openID, bringing me to my next point:
The thing I just mentioned CAN be made by an openID provider (I was surprised that I couldn't find such a provider though), and it would make a lot more sense to mak
Re: (Score:3, Interesting)
And the strategy still has a key advantage over smart cards with displays, namely the logistics problem.
Re:Yes, we know. (Score:5, Funny)
I have you beat (Score:3, Funny)
Re:Yes, we know. (Score:5, Interesting)
The US Government uses this method, except via smart cards. This started with the NMCI initiative. I was not keen on NMCI, as it used Citrix and centralized application serving. This creates a single point of failure (which quite often failed at the beginning) and a single, all-powerful account on a system (there's no other way of having a central system responsible for all privileges otherwise) on an operating system that probably isn't going to be in the Trusted class (ie: it ran Windows - and I am using the Trusted class in the Orange Book sense, not in any "popular" sense of whether people actually trust it).
PKI is a very sensible approach, but should not be used in isolation. This was discussed only a short time ago on Slashdot regarding "secure locks" - there should always be multiple layers of security, a reliance on a single layer is always going to be a disaster waiting to happen.
Passwords as a "bootstrapping" mechanism to enable the rest of the security sounds fine. It's something we already do with regards GnuPG/PGP keys, Kerberos, etc. They're weak, but bootstraps don't need to be that strong if you're using them in a multi-layer system. They're supposed to make it hard for anyone to tell if they've broken the other layers. That is sufficient.
There is, however, almost nothing else you can use. Biometrics are not safe (Slashdot has covered the breaking of many such systems) and not guaranteed to work (Slashdot has covered chimeras and other biological weirdness in the past). Two physical electronic keys won't give you significantly more security than one with twice the quality of encryption and just give you more you can lose. Call-back mechanisms are vulnerable to social engineering (if involving people) or replay attacks (if automated) since such methods have to use extremely primitive security as they are prior to authentication.
Re:Yes, we know. (Score:4, Interesting)
And you can do that with openid. I got bored and made myself a GPG based openid provider. It isn't complete by any means since it lacks key revocation and such, but it is working and public.
http://id.l3ib.org/ [l3ib.org]
I actually use a smartcard every day (Score:4, Informative)
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.
Re:something you have? (Score:5, Funny)
You can't prove you have the "something you have" as in reality anything can be copied and thus you might just have a copy. Most of the token "things" are really a case of "something (something you have) knows" which isn't much better than "something you know".
Right?
Right. Moreover, given a good hacksaw, biometrics can easily move from "something you are" to "something I have."
Re: (Score:2)
Hell, you don't even need that much with finger/voiceprints. The only thing I'd be apt to trust is a retinal scan. (And only with a camera nearby for later verification.)
Re: (Score:2, Interesting)
Still, punishment for murder is much greater than punishment for breaking into a computer system. Which means, the degree of effectiveness of a retina-scan biometrics is still formidable.
Now that I come to think of it, I also see that a password can be known by torturing the person who knows it, while the point of torturing a person for retina-scan or retina-sample is rather moot, I suppose. I am not sure what is more "pleasant" - to be dead or to be tortured.
Re: (Score:3, Interesting)
....The complexity of cloning security tokens varies....
Who needs to clone or copy anything? Nobody has ever car-jacked a vehicle by sticking a gun in the owner's ribs and demanding the ORIGINAL key? Nobody has ever robbed a "secure" vault by kidnapping the person who has legitimate access to that vault, key, combination or both?
Anyone who can come up with a security system that uses NEITHER what you have nor what you know would win a Nobel Prize and become extremely rich.
"Beyond Passwords" (Score:4, Insightful)
That almost sounds like a....password...
Really, this is an article about using things instead of passwords....which function like passwords....and using passwords when those wouldn't be secure enough. What a stupid fucking article.
Re: (Score:2, Interesting)
Re: (Score:2)
It's still a password. It's a password that is used for authentication in a different way, but it does not move us "beyond passwords for security"
Re:"Beyond Passwords" (Score:4, Informative)
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".
Re: (Score:3, Interesting)
But it's not smoke and mirrors, IF you're looking at the realm of threats to your data/transactions on the internet.
What makes your password so valuable today is that the password alone is sufficient to unlock access to all your online data.
A two factor auth mechanism renders the password effectively useless, especially if the smart card implementation is competent. At a minimum, it raises the bar for the attacker dramatically higher than it is today.
It's not possible to have perfect security. All you can
Kerberos did that years ago. (Score:5, Interesting)
With Kerberos, your password never leaves your machine.
The machine you're trying to log on to sends you a random string that is encrypted with your password.
Your machine uses the password you typed in to decrypt that string. Which also contains instructions on how to continue the connection.
Your password never goes across the wire.
Re: (Score:2)
Hell, even NTLM did that years ago.. it's not rocket science.
The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP. It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).
Re: (Score:2)
I know very little about HTTP AUTH, but wouldn't an easy solution to this be to allow other authentication mechanisms to be submitted with a form?
Re: (Score:3, Informative)
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
Re: (Score:2)
Re: (Score:2)
Except this means the server can't store your password as a hash... it has to store your actual password, which means if someone gets access to that server they can steal all the passwords.
The server can encrypt the passwords, but it has to be able to decrypt them, so it needs to know the decryption key too. Which can also be stolen the same way.
Re: (Score:2)
PN usually are passwords, but they are simpler and unique (some user have a single sign on, but this is a bad practice).
Re: (Score:2)
someone, preferably in NY, should call them up and explain they don't know what they're talking about. i wonder how much they'd pay for a proper article putting the OpenID story straight?
Convenience vs security vs stupidity ... (Score:5, Insightful)
Passwords can still play a role, the problem has always been user stupidity and convenience vs security. We always love to save time and anything that requires less effort = good for us, but at the expense of being less secure. Moving security to invisible layers is just asking for abuse by authorities, as if they didn't have enough power already via MAC address + ip binding in being able to track down and identify users by merely tooling around with the equipment right at the ISP end.
My bank uses multiple authentication using personal questions which I would only know the answer to and if you get the question wrong just once, it flags the account. The big problem is the amount of retries, you can't guess or brute force passwords on accounts that will lock after the first few failed attempts.
In my opinion it's probably best if we moved to gesturing, I find an interesting site here -
http://www.dontclick.it/ [dontclick.it]
It could serve as an interesting basis for security, i.e. gesturing and opening the correct doors in a maze.
Re:Convenience vs security vs stupidity ... (Score:5, Interesting)
Re: (Score:2, Interesting)
The one thing that has always bothered me about retry lockouts is the denial-of-service opportunity. If someone knows your username, then they can harass you by expiring the retry limit. Even worse, they can let a bot do it. They won't brute-force your account, but they can ensure that logging in yourself is a huge headache.
Perhaps a modification to the retry lockout strategy would be to make it per-IP address. It would shift the danger to large botnets, which could still distribute the password atte
Re: (Score:2)
"Of course, now this makes processing logins expensive, as each attempt requires consulting with a retry-blacklist. One might try making a single, global blacklist and then dealing with the support calls from people with infected machines who were blacklisted for testing other accounts without their knowledge.
Tough game to win, really..."
Well this is why banks could keep a record of IP's you login from and only block permanently those that according to the logs are rarest in successful login attempts.
Re: (Score:2)
I like that idea, especially if whoever sets up the gestures has a bit of imagination and a sense of humor. I'd love to be able to open a door just by walking up to it, holding my left hand up at shoulder level and snapping my fingers. Clapping my hands three times at waist level would be another neat idea. Set it up right, and it would feel like you were in a magician's lair, and that there were
Re: (Score:2)
"Ok so I've saved time by not clicking on links, but what if there's something I want at the bottom of the screen, but there are all these mouse-over links between my cursor and it. The screen is suddenly a minefield."
But if you read the site it was experimental, i.e. the design issues using gesturing would still have to be worked out. IMHO it's not a BAD idea, it's not a replacement for buttons, but it is another way of thinking about things. I think the big problem was merely a problem of implementation
Speaking of passwords (Score:2, Funny)
I like that slashdot hides your password if you accidently type it into a comment.
Look: **********
Re:Speaking of passwords (Score:5, Funny)
Surely that can't work... if it hides your ******** whenever you type it, then it would make it really obvious what your ******** is if it's a standard dictionary word when you use it in a sentence. I don't think it masks ********s at all.
Re: (Score:2)
and that is why your password should never be a simple dictionary word.
Re: (Score:2)
It only works for your own password. My password is **********. See?
Re: (Score:2, Funny)
did it work?
Re: (Score:3, Informative)
Sure, all I see are stars.
yes, it's a classic. http://www.bash.org/?244321 [bash.org]
PEBKAC (Score:5, Insightful)
Comment removed (Score:5, Insightful)
OpenID (Score:5, Insightful)
OpenID is _PERFECTLY_ compatible with passwordless authentication. For example, my OpenID provider uses Kerberos authentication.
I too feel that passwords are too weak. Something like special hardware tokens are much better, but there's no infrastructure for their distribution.
Re: (Score:2)
That is something held, not something known. Someone can take your something held. Ideally you would have both.
Re: (Score:3, Insightful)
For most applications "something held" (maybe with a simple PIN-protection) is perfectly fine. Like your keys, for example.
Good key revocation system is essential in this scenario, however.
Passwords are much overrated, anyway. Most users inevitably either choose weak passwords or just write them down somewhere.
Re: (Score:2)
A PIN is a password. So you are saying something held is fine, if you have something known too.
My car has a much easier known-exploit, the infamous rock to window method.
Written down passwords are not inherently bad.
If they are kept in a safe place, say a wallet, and they are not marked as to what they are for it can be an acceptable practice. Especially if very few attempts are allowed.
Re: (Score:2)
A PIN is a weaker form of password. It also relies on hardware (to lock you out if you enter PIN incorrectly several times). It's useful to make simple attacks (like stealing your token) harder.
A written-down password is less secure than a hardware token. Because you can simply copy the written password (and use it later) but you need to have a physical token to use it. Of course, assuming tokens are not easy to clone.
Re: (Score:2)
My bank has quite a good solution. They provided me with a pin pad, which i use in combination with my (chip&pin) bank card. When I need to make a transaction online, I am presented with a code. I enter this into the pad along with my pin, and it produces another code, based upon the key held in the chip. This can also be used for identification by producing a time-based code similar to RSA keys.
Re: (Score:3, Informative)
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.
Re: (Score:2)
Somthing held = a card with 1000 5 letter sequences.
Something known = The "algorithm" you change those 5 letter sequecnes:
copy the last two letters, in reverse order to the front. Add the two digit day of the month (or minute) to the end.
The host chalenges with a number: 567
You look up "SBEce"
You key in "ecSBEce10"
Possible Changes:
copy or move:2
To the beginning or End:2
First two
center three
last two
first three
last three:5
Reversing them or not:2
add 2 digit minute
add 2 digit day"2
To the beginning or end:2
add t
Re: (Score:3, Insightful)
Something like special hardware tokens are much better, but there's no infrastructure for their distribution.
They're also not cheap.
Re: (Score:2)
There's no real reason for it.
They are expensive because demand for them is low and economy of scale doesn't have a chance to kick in.
Combine it with a lot of conflicting proprietary implementations.
Re: (Score:2)
The WoW ones cost 6 euros a piece.
The Wow ones are subsidised. securID tokens are typically around $50/50 each when purchased in bulk.
Re: (Score:2)
They cost way less than that.. A quick google found them genuine RSA ones being sold retail for a US equiv. of $40 each.
The WoW ones are 3rd party and produced in bulk (and allegedly nowhere near as sophisticated as RSA ones), so I don't think they're subsidised much if at all. Blizzard have previously said they're being sold at cost, not subsidised.
The real price gouging on these things goes on at the server side.. a securid appliance to use all these keys runs to about $8000... but that's peanuts to the
Re:OpenID (Score:4, Interesting)
Also, many OpenID providers like MyOpenID [myopenid.com] let you generate a browser-side SSL certificate and forbid password logins entirely on your account. At that point, you can't be tricked into entering your password because you simply don't have a password.
b.authenticator (Score:2)
Something like special hardware tokens are much better, but there's no infrastructure for their distribution.
I seem to recall a rather high profile [google.com] company introduce a hardware token to assist with account security, it was greeted with much enthusiasm [wowinsider.com] by it's customers. Yet before long, it too, failed [wowinsider.com] . [wowinsider.com]
Re: (Score:2)
So? Of course you can screw up anything.
Re: (Score:2)
It didn't seem to fail except in the sense that it doesn't provide 100% from all possible methods of attack. If someone is able to get physical control of your token and learn your password then you have bigger problems to worry about.
Re: (Score:2)
It fell to a social engineering attack.. blizzard screwed up basically (should have demanded photo ID but didn't).
Even the most secure systems can fail in that manner if the human side fails. One of the first things that's done when security is tested in an organisation is phone up, make up a story and see if the person on the other end will give up a password.
Of course the reason the hacker had enough information to pull that off is the owner was an idiot and gave their details away - probably responded t
Re: (Score:3, Insightful)
Something like special hardware tokens are much better, but there's no infrastructure for their distribution.
USB thumbdrive, passphrase protected private key.
Once sshd can tell if a private key has a passphrase and its authorized keys can be centrally managed, then there is never a reason a user should ever type a password. Just unlock the private key locally, and you can go wherever you are already authorized to go.
I just think its so stupid that we have to type usernames and passwords all the time. The
Re: (Score:2)
I mean this is the way credit cards work. No password whatsoever, and I can present my card, and a purchase is made, no password ever.
Yes. Isn't it encouraging how credit cards are far less secure than my virtual server?
I mean, I don't use a username/password to enter my $500,000 house, or to drive my $100,000 car,
No, but you hopefully are using a key, at least. And I know some of us use combination locks -- which is, you know, entering a passcode to get into your house or car. Or office.
If you don't use either, would you mind posting where you live?
Re: (Score:2)
Anyone who holds your credit card can charge until you report it stolen.
Nothing stops anyone from breaking and entering your house except "law" - brick+window, or crowbar + back door, or bumpkey + front door = entry.
Your workplace has a kind of password - the people you work with recognise you. Try walking into some random place where you don't work - even a big company where there are too many employees for everyone to recognize everyone.
You may be able to cart off a computer with the right ploy. On the ot
My reply, directly to the author: (Score:5, Insightful)
I felt I had to respond to your article about passwords. It's been Slashdotted here:
http://it.slashdot.org/article.pl?sid=08/08/10/186203 [slashdot.org]
But I felt it was important enough to write directly, and concisely, because you seem to have missed a fundamental point of OpenID.
OpenID promotes "Single Sign-On": with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.
OpenID supports single-sign-on. There is nothing about it which requires you to use the same identity everywhere -- or even the same provider.
But more importantly:
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.
Nothing about OpenID requires a password.
I'll say that again: NOTHING about OpenID requires a password.
What OpenID does is, in proper implementations, it allows us to sign in with any provider we choose. I could choose my own server as a provider -- thus, it's not necessarily "someone else's web site". And I don't have to use passwords -- I can use a password and a "security question", I can use public-key cryptography, or I can hire a secretary to sit at the server in question and only authorize requests when she receives a phone call from me.
Even if we assume everyone continues to use the same password, with the same account, everywhere, it's still better than a conventional login. With the conventional login, every site I log into could steal my password and use it to login as me elsewhere. With OpenID, only my OpenID provider can do that.
One single-point-of-failure is better than N single-point-of-failure.
You can't use Microsoft-issued OpenID at Yahoo, nor Yahoo's at Microsoft.
If true, that seems about on par for a technology in its infancy. Remember email? Used to be, you could only send mail to other people with the same ISP. Now, I can send mail to anyone, on any ISP, so long as I have their address.
So that says more about Yahoo and Microsoft's understanding of the technology than it says about the technology itself.
Re: (Score:2)
Thank you.
The level of ignorance about what OpenID is or isn't is fairly staggering even amongst technical people.
I think the OpenID people have an uphill battle trying to educate the masses. I hope they can succeed, but I have my doubts.
Re: (Score:2)
I think a lot of the confusion is because OpenID was presented early on as an alternative to Microsoft's Passport - which is exactly what GP was rebutting.
Example of no password (Score:2)
Re: (Score:2)
They present you with some pictures - you pick out the ones that fall into the catagories that you picked earlier
How is this relevant?
Oh wait, I know: If Vidoop was smart, they'd become an OpenID provider. (Maybe they have already?)
That was the point: If OpenID is widely adopted, then you can use things like Vidoop anywhere you want, so long as they support OpenID. The sites you're trying to authenticate with don't even have to know about Vidoop, much less go out of their way to implement it.
Re: (Score:2)
So a single point of failure that allows someone access to everything is better than multiple points?
Which allow access to everything, yes.
You neglect to understand that with passwords, you can use different passwords in different places.
True. However, most people, out of convenience, only use a small number of passwords in those different places.
OpenID certainly doesn't require you to use the same identity everywhere, either, or even the same provider. In your own language, this is a simple grain of truth that you don't seem to be able to see or understand.
But, for the same reason someone might want to use the same username and password everywhere, people will likely use the same OpenID login everywher
Re: (Score:2)
Again, one single password allowing access to everything is the fault of the user, not the password authentication system.
Doesn't the same apply to OpenID, then?
But doesn't that defeat the idea of OpenID? Why not just use passwords, then?
Because you still get the ability to choose a provider, and an authentication method, rather than being forced to use whatever the site admin setup.
The point is that OpenID doesn't reduce your security in any way, unless you alter your habits because of it.
You don't understand the difference in posting AC and under a user, where negative moderation affects karma (in this case, unfairly)?
Given that ACs have no karma, no I don't, unless you have an account you're trying to protect.
And how do these magical physical tokens somehow magically directly bypass the physical terminal and go directly to the site in question?
There's nothing magical about it. Here, go read. [wikipedia.org]
Now, it does still have the implication that you've authenticated the loca
Re: (Score:2)
when the central authority is compromised, all my sign-ons could be compromised.
You're missing the point.
I am saying that one single-point-of-failure is better than N single-points-of-failure.
If you use the same password everywhere, then everywhere you use that password is every bit as much a single-point-of-failure as your central authority.
Personally, I like the fact that I can control everything and I do use super-strong passwords (if that's not an oxymoron) for my 'important' accounts.
So, you could use a throwaway OpenID account for unimportant accounts, and a super-strong OpenID account (or more than one! Imagine that!) for your important accounts.
That's not to say that my stuff couldn't be compromised, but personally, I am more comfortable with controlling it myself.
Then you should be, not walking, but running to get OpenID implemented as many pl
Re: (Score:2)
Yeah, OpenID can work with just about any authentication scheme, all without requiring you to provide your credentials on someone else's site.
A much more apt criticism of OpenID would be that it relies on DNS for authentication purposes, and DNS is fundamentally insecure. Why bother stealing passwords when you can just poison the cache of an OpenID site's nameservers, tricking the site into authenticating users against a bogus OpenID server of your choosing?
Re: (Score:2)
In theory, hardware tokens can also authenticate that the OpenID server is the real one.
Re: (Score:2)
Right, but that's not actually relevant to the type of attack I'm describing. I should have been more clear:
Suppose Alice runs a web site at http://alice.example/ [alice.example], which uses OpenID to authenticate its users. One of her web site's users is Bob, whose OpenID URL (http://bob.example/) delegates http://charlie.example/ [charlie.example] as its OpenID authority, by using the requisite HTML tags in his web site:
Re: (Score:2)
Yes, it's a weakness. We really need to speed up DNSSEC adoption.
In fact, I'm going to install it on my DNS servers ASAP.
Re: (Score:2)
No, it's more like RSA tokens used in Internet-banking.
TPM ensures that no 'untrusted' code is running, hardware tokens are used to ensure your identity.
We need more passwords... (Score:2)
...and we must enforce their strength and use like bastards.
Let us not be pussies about this, short of submitting a biometric signature every time I want to authenticate just how else can a machine tell I am me?
Re: (Score:2)
Let us not be pussies about this, short of submitting a biometric signature every time I want to authenticate just how else can a machine tell I am me?
You could implant an RDIF chip to someone heart which only functions when the heart is beating so if someone removed that it not longer function.
A little extreme, but no one could ever call you a pussy.
Re: (Score:2)
No, they'd call me Harkonnen.
This could just be my ignorance- (Score:4, Insightful)
Re: (Score:2)
But doesn't this restrict people to using secure sites only from their own machines?
Yes, yes it does. Several commenters have suggested workarounds to this, like carrying memory sticks with all your keys and the like. But I think it's highly unlikely that will never catch on. Personally, I don't see any problem using passwords, as long as the user is smart about usage (i.e. no public terminals, use only over encrypted connections, mixed upper/lower case/numbers/special characters, keep it secret, etc.).
But to be fair, no, I did not RTFA.
Re: (Score:2)
Yes, that's THE big problem. I've messed with it a couple of years ago. I wanted to make it work under Linux as well as Windows. But in the end it only worked partially and it wasn't really practical.
To make this kind of thing practical you'd have to define an absolute standard for smartcard authentication.
This probably means that there should be an USB standard that is as compatible with all smartcard vendors as "universal mass storage" is for usb storage. And all applications, ISV's and service providers
totally safe authentication method! (Score:5, Funny)
Beverly Crusher: Computer, Commander Beverly Crusher. Confirm auto-destruct sequence, authorization Crusher-two-two-beta-Charlie.
Worf: Computer, Lieutenant Commander Worf. Confirm auto-destruct sequence. Authorization Worf-three-seven-gamma-echo.
Computer: Command authorization accepted. Awaiting final code to begin auto-destruct sequence.
Re: (Score:2, Interesting)
Of course, I don't remember any time where Worf tried to use Riker's credentials, so I can't really back it up...
Re:totally safe authentication method! (Score:4, Interesting)
IIRC, Data has used Picard's credentials, and he was impersonating his voice, so that would support your theory.
Regards
elFarto
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Sheridan: This is Captain John J. Sheridan. Serial number XO7Y39-Alpha. Security code: obsidian. .
Ivanova: This is Commander Susan Ivanova. Serial number Z48M27-Epsilon. Security code: griffin.
Michael Garibaldi: This is Chief Warrant Officer Michael Garibaldi. Serial number V17L98. Security code: peekaboo.
. .
Ivanova: Peekaboo?
Garibaldi: Would you have guessed it?
(linky [wikiquote.org])
How could it blame OpenID? (Score:3, Interesting)
OpenID does not required the use of password as the way for human to authentication oneself to the system.
It's just up to the OpenID signatory to use whatever technology to authenticate someone. This human interface is decoupled with the underlying authentication.
Although most public signatory currently use username+password, but it could be change. Say you could implement your own, using PKI to recognize your own certificate stored on removable media. If you gone crazy enough, nothing stop you from implementing One-time password + Biometric + whatever-you-can-think-of to authenticate yourself to your own signatory.
its not that hard (Score:5, Funny)
i have trouble keeping track of all my usernames and passwords like everyone else
so i put it in passwords.txt in my shared emule folder, so i can access it anywhere in the world ;-)
smart, huh?
What about digitags? (Score:3, Interesting)
In South Africa, everyone with a bank account by law has to undergo a KYC process (know your client). This basically means that you as a client have to verify your ID at a branch (in person) with ID documents and some of your monthly bills. Your cellphone number is then captured to which all notifications of activity on your accounts are sent.
The Digitag [actividentity.com] is used during online authentication. As a further backup, a one time pin (OTP) is send to your cellphone. This OTP is required for certain transactions like once off payments.
Granted the system is not perfect (there is still human stupidity), but I would like to hear your comments on these tpye of systems, as they are becoming more and more part of our lives.
OpenID and Multi-Factor Authentication (Score:4, Informative)
MyOpenID (Score:3, Informative)
Cryptographic login (Score:2)
I've been doing that for years with SSH [berkeley.edu]. Funny, that.
Re: (Score:2)
All we need is for websites to accept the public key strings, and the browsers to interact with ssh-agent. It would take someone like Google to accept this type of thing for gmail for it to get any kind of acceptance.
Re: (Score:2, Insightful)
Graphical Pattern Method (Score:4, Interesting)
At my university, they were trying an experimental password alternative that comp-sci students could opt-in for.
Basically, we were presented with an image; this particular image was a bunch of cars in a parking lot, with people walking or standing around. I think it was a 400 by 400 pixel image. To set your pattern, you had to click and memorize five or six arbitrary points in the image, and also memorize the order you click them in. The idea was that it was supposed to be a lot easier to remember than an equally powerful password. Some people liked the new system, while others had a lot of trouble remembering the exact position of each of their clicks. I fell into the latter group.
Re: (Score:2)
EXACT position? You'd think a 'fairly close' position would do. For people walking, car park etc, you'd probably go with a specific car or face/hand/leg rather than [327;173].
Can you trust a solution you don't control? (Score:2)
Solutions based on technology have a simple but critical flaw: When they break, they're broken and exploitable despite anything you could do. The human factor is not only a security risk, it can also be a security asset. Humans are far better at plausibility checking, if they have proper training, of course.
Modern machines, no matter how resilent the technology behind them, offer inherently such a variety of possible attack vectors, that nobody can say with certainty that no attack can be performed. I would
Or you could use OpenID with a smartcard. (Score:2)
E.g., Trustbearer is an OpenID provider that will leverage smartcard-based PKI keys for authentication. Best of both worlds.
https://openid.trustbearer.com/ [trustbearer.com]
The way this works is by something called "key continuity management" (KCM). Users of SSH RSApubkey authentication will recognize how KCM works. Everyone else should read Simson Garfinkle's "Johnny 2" paper:
http://www.truststc.org/pubs/5.html [truststc.org]
In short, KCM works by establishing trust with a specific key, ideally by an out-of-band channel. If you establ
How about PGP, server has public keys (Score:2)
What about this:
The server has the public keys of all the users, and encrypts (with the public key) a one-time string for a logging in user to decrypt. When the user has decrypted the string, they enter that as the password, and get access to the system.
For users who do not have a stored key (or have an invalid key), the server would transmit a random string and not allow any entered string to work. The error message would be something like "invalid passphrase or user not known" [or just the usual "login in
Re:the real solution! (Score:4, Funny)
We already tried that. It's called 4chan.
It did not work that well though...