Google Declares War on the Password
wired.com
wired.com
If you got passwords, users either pick easy ones or write them down next to the device that needs them. If you require physical "key" items, user leaves the key next to the computer that needs it.
When designing a security system you need to acknowledge this limitation, and design the system with it in mind. Running between "something you know" (passwords) to to "something you know and has" (Two-factor authentication like password and phone), and now back to only "something you have" (an USB key) won't solve the problem.
I would say for consumer it's already better than passwords. Biggest threats seems to be password-reuse (and hacked servers) and phishing.
That can be easily solved by integrating a good password manager into the browser. There are plenty of plugins that automatically generate random passwords, insert them into appropriate form fields, and save them in a secure "vault" that is synched across devices. It shouldn't be too difficult for browser vendors to offer such functions by default, and gradually upgrade them to incorporate newer standards.
At least, it will be much easier than getting everyone to purchase a physical device, and it's even backwards compatible with existing sites that will probably stick around for another decade or two. I doubt that any solution to the "password problem" will be viable unless it were backwards compatible.
They all keep them on their key chain so I don't agree with your premise.
The only thing I never understand is why, like the device pictured, they're designed with strings and thin plastic instead of chains and a beefy case.
The key to this is to still require something that you remember like your username (and/or a password), they will get stolen and it is too risky for these tokens to be the only authentication factor.
As long as users are educated that these tokens should in all ways be considered a set of keys then security can only be improved with them.
Of course, people still leave the key at the computer when they go and eat, bathroom, or when they leave the building as a group.
For work purposes, i.e. you need it to do your job so it may be required at any point. TFA is saying people will leave it just by the PC they use most often, i.e. at home, which defeats the point.
I think the use of smart phones for 2-factor is the way to go, since it is not something else I need to carry around. Up until recently Barclays Bank (in the UK) had a fairly bulky card reader which I would insert my card, tap in my pin and it would generate a secondary password (I also have to chose letter X and Y from my password). They now have a smart phone app. Much simpler for me now.
You could go for biometrics. But that creates a new problem - unless you're deeply paranoid, you'll leave plenty of DNA, fingerprints and pictures of your irises, without thinking of them as security holes.
You could tie it to the device. But that's no good when you want to check your email on a friend's computer. And if your phone gets stolen with full access credentials... The device is not the same as the user. So I don't see how you can avoid some combination of 'something you know' and 'something you have'.
Biometrics are a terrible idea. Password + token is much safer and infinitely revokable. And the server can even tell when an HOTP device has been cloned.
Personally, I think most biometrics are bunk, unless you use multiple (fingerprint, iris, etc) along with some kind of password.
What does that mean in practical terms? It depend. It can sometimes mean to move the question of validation to a third party. It can sometimes mean multilayer security, so once the first line of security features goes down, the damages done can easy be reverted. It can even be insurance against liability so the user's security mistakes do not damage the user. In some cases, one could have a complex revalidation system instead of an complex validation system, so that its first when a user switches a device (say a phone) that all the non-transparent security will show itself. It all depend on the exact details and what the exact threat model is and who the intended user is.
This is why in my mind, articles like this one are missing the point. They are trying to announce a silver bullet, when such thing does not yet exist even in theory.
I don't disagree with what you wrote about going back the "SYH" being not that smart but...
It's not transparent when my 65-years old mom uses a physical device not connected to the computer, in which she enters her identity (Java SmartCard) card and perform a manual challenge/response to login and do her online banking.
It's a pain for her: it's SYK+SYH but it beats going to the bank all the time... So it's not transparent but it still works because she doesn't really have the choice.
The contacts get dirty, they dont fit some USB ports properly, they die regularly, are absolutely no good if you don't have a USB port handy (my desktop for example doesn't have a USB hole in the front or on the keyboard or monitor, resulting in crawling around under my desk to authenticate) and to be honest quite fragile.
All it does is act as a USB HID keyboard and pump some text down when you press the button on it. It's basically about as secure as an RSA key but requires physical electrical contact with the machine.
No thank you.
(For reference http://bigv.io/ uses these).
Not necessarily. They can be configured for challenge-response auth: http://www.yubico.com/products/services-software/personaliza...
Another problem is they don't work if the OS is configured to an alternate keyboard layout. The default hex encoding assumed QWERTY, but I use Dvorak. Perhaps this has been remedied in newer models.
I've got some hard to access USB ports, too. I solved that problem by buying some USB extension cables (male on one end, female on the other). They are very inexpensive. Give them a try, you won't be disappointed. No more uncomfortable hunting for USB ports under the desk!
"In a 21 March 2011 email to customers, RSA essentially admitted that the information stolen from their internal network could allow an attacker to compromise a SecurID-protected system without having physical possession of the token."
http://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_c...
So passwords are a bad idea, but I'm not sure if I want to replace a problem with a different one.
[1]http://www.yubico.com/products/services-software/validation-...
According to Fedora wiki they're used to create OTPs (one time passwords), but still... I don't like the idea of a physical token that can be stolen and used without verifying the user (meaning that you still need user/password or any other auth mechanisms to complement the Yubikey).
If you run your own server, though, you can set up challenge-response on the Yubikey which might make things easier by allowing maybe a PIN instead of a password.
Hopefully one day soon we will be able to authenticate with behavior; maybe a combination of gate/speech cadence/facial structure. Or maybe like a Rorschach test instead of username/password field :)
This is somewhat equivalent to losing your ssh private key. Yes, it's bad, but your passphrase should ("should" -- at least it's not an immediate breach like losing a password or clear text private key) buy you enough time to revoke and replace the key.
1) Know something
2) Have something
Its somewhat easy for a potential cracker to gain access to either one of the two, but extremely difficult to have both.
Hell, when I used SecurID at one of my first jobs you had a PIN to go with the token number, almost like a salt to your password. Even if they had the key they wouldn't be able to access my accounts.
What happens when you want to leave Google services?
You will be locked in. I remember the days when everyone had hotmail. At some point you will want to leave gmail or google apps. Genius move on their part though.
My work blocks Google Account access so I can't quite verify this for you, but I believe it's there. I'm not sure how far it spreads across their product offerings though at this point.
The tool to export data from some of their services: https://www.google.com/takeout/
You can set up an IMAP/POP connection to GMail and copy your emails out. gmvault (a third party tool) uses that to make backups.
The parent post was talking about the OATH (http://www.openauthentication.org/webfm_send/1).
I think if a mammoth like Google pushes forward strongly enough, it might achieve some results. And it probably takes all its mass to push this particular piece - the almighty and alstupid password, away.
I'll bet that human beings in 20 years, looking back at our times, will point fingers and say "How we have been so silly! Passwords are the worst authentication mechanism, and so obviously flawed! How come did we not use x or y?"
I see another thing that they will point fingers at: the human driven cars: this is so frightening, when you think about it. You have this thousands kilogs wheeled machine, driven by almost anyone including drunkyards, grannies, people who just married and people who just divorced, and a sec of inattention and you send families to the grave.
Passwords (plural) are just about the worst authentication mechanism. While brains are good at remembering one such token, needing to remember many for many different sites (and which ones go to which) is simply untenable. Additionally, the ability to easily compromise them through phishing makes them awful.
I wonder if there'd be a way to cleverly move the hashing (that all servers should be doing) to the client side such that all of the above problems could be solved. It would confound password changes, however...
With random, unique passwords, resource-intensive server-side hashing provides no benefit. We are doing that because people re-use their passwords everywhere.
Option 1: your passphrase as a salt + the domain name + bcrypt = password. Lots of detailed schemes exist for this, including ones you can do on a piece of paper with a little math so you don't have to trust your computer. Inventing them seems to be a hobby for crypto people, or something - I've seen many dozens.
Option 2: you use random passwords, and store them behind your passphrase somewhere. Password managers.
At no point does your single, secure password enter anyone else's hands, so you don't need to trust them to hash it. If one is compromised, none of the others are.
Password managers (especially in terms of built-in browser support) are generally a one-machine solution. Yes, there are ways to sync them to mobile devices and the cloud and such, but there's a lot to be desired in terms of portability. I currently use 1password, and it works great for me. I set my mother up on it, too, but it's only a 90% solution for her as she's not quite technically proficient enough to ensure it works all the time.
My question was more if there'd be a smart way you could add one more level of indirection such that: 1) individually compromised passwords could be changed and 2) the master password could be changed without affecting every single site.
Ideally neither situation would be necessary, but servers will be compromised.
1) domain names change sometimes. especially with the current trend of weird ending domains, and "www.getx.com" which later becomes 'x.com' when they finally pay the squatters. Or a rebranding, or subdomains, etc. How do you handle changes, without recording them? Proactively you can change your password when such a thing occurs, but that's not a reliable assumption.
2) versioning. If you have to change a password every X time periods, how do you track which version you're on? without a database? you could salt it with the time the last password was created, but what about time zones? different calendar systems (did I set that password in china, or jerusalem, or canada...?)?
All of which leaves you with a database of some kind in some (fairly likely to occur) situations, which means you essentially have a password manager. As you point out, a 90% solution simply isn't good enough.
I use LastPass, and it's about as cross-platform as any app can be. You just need to reconcile yourself with the fact that your passwords will be uploaded (encrypted, of course) to a third-party service. It's also a piece of cake to change individual passwords or the master password without affecting anything else. Most importantly, you get the same anti-phishing benefit as option 1 because LastPass won't offer to auto-fill your password if you're on the wrong domain. You don't get this benefit if your password manager is outside your browser.
* Checks my posture.
* Checks the sounds I make while sitting neutrally.
* Checks the positions of my hands.
* Checks my overall frame.
* Checks my eye and shape of face.
---
Hopefully, all of these little things add up and in the end it can determine quite easily whether it's "me" or not.
I hate typing in passwords, it's a pain in the ass.
"What do you mean access denied - I've just got a back ache!"
Although a counterpoint to this would be using more unique points of reference like the iris, fingerprints, etc, things not likely to change.
Imagine if the "forgot password" link on a website gave you a form that said "enter your current password and then you can set a new password". This is the scenario you're describing.
> That means that if someone steals your card or your smart-ring, you’d better report it stolen pretty quickly.
I won't be surprised if thieves devised a method to extract online credentials from a stolen device in a matter of minutes, if not seconds. Since any password you have on your mobile device is unlikely to be strong (the article specifically mentions that you won't need a strong password on your device), it will also be a piece of cake to brute-force it. Meanwhile, you're without a phone, desperately looking for a payphone or Internet cafe where you can contact Google. Too slow.
At Clef(clef.io) we're storing keys on your smartphone and they're protected by a PIN wall. We used PIN-based encryption to keep a rooted device from being vulnerable to attackers. Generating the keys from the PINs take long enough to make a brute force attack time consuming. Since users can deactivate their devices remotely if they're stolen (so the public side of the key pair is deleted and the private side is worthless), even in cases of device theft, their identity is protected.
Those of you how own Dell or HP Computers - you may notice that most of the professional grade laptops have smart card readers built in. My guess is this is due to DoD purchasing requirements. Of course, the MacBook doesn't have a smart card reader and thus you start to look for solutions like the YubiKey.
i guess we need 3 factor authentication, yeah, that's the ticket!
The idea of using a smartphone as a central area for things such as identification and payment(Google Wallet) has been something i've been interested in for a while, and something I think could be amazing if we manage to work out a few kinks that are in the way of making it a viable option.
For this to become a reality i think there are 3 main things that would need to happen: 1) Battery life on smartphones would have to become a lot better, I don't want to have to worry about if I'm going to have enough battery at the end of the day to pay for dinner, get into my car, etc. 2)The ability to remotely clear data on a device that may have been stolen need to become a standard. 3)There need to be some sort of authentication between the user and the device in order to approve the use of stored authentication.
Remember AMEX Blue? they stopped sending out card readers almost immediately, but continued sending the smart cards out and running TV ads with all sorts of Terminator like special effects to promote how secure its smart cards were.
It was a huge marketing success, but the smart card part was never used.
Security is an illusion.
Actual conversation.... Naive dev: Hey Big Bank, we invented this revolutionary perfect authentication technology! no more hacks! Big bank: why would we want to redirect the hackers to a new attack that we don't understand, cannot model, cannot assign a stable cost to, and would almost certainly expose even worse flaws in other parts of our systems? as long as fraud is between X and Y %, we WANT the attacks to use the current vector. Naive dev: ooooooooooooooohhhhh (world view changes)
You're totally wrong. Probably because you're living in the U.S., where it's still the stone age from that standpoint.
http://en.wikipedia.org/wiki/Smart_card
Here in several european countries people are doing just that:
- using a Java SmartCard (your identity card) + a card reader (not hooked to the computer) + a PIN to connect to your online bank but ALSO to challenge/response any VISA/credit card transaction.
If I'm not mistaken there are about 200 millions citizen in Brazil who have a Java SmartCard as their identity card (as a medical care card I'm sure, identity I don't know for sure).
I think it's a bit early to decide that it failed and that it's an illusion. There are probably hundreds of millions of people who are carrying daily a Java SmartCard and using it to perform kinda safer online transactions.
MITM attacks over unsuspecting users are still possible using "mocking birds", but it's becoming harder and harder to game the system.
Also, thanks for the down vote based on hard facts: "probably hundreds of millions", "kinda safer". http://www.techspot.com/news/51037-trojan-bypasses-two-facto...
An identity card is not a commerce solution -- there is no cost/benefit analysis for governments, they just decide which vendors should get lots of money (I know, I was one of them! Thanks governments!) We did this in the US and now there are no fake passports here in the US, we win! Ooops... http://www.schneier.com/blog/archives/2006/08/hackers_clone_...
A card reader not hooked to the computer --- nah ,that can't be hacked: http://media.blackhat.com/bh-us-12/Briefings/C_Miller/BH_US_...
smart card PINs, those can't be hacked: http://blogs.gartner.com/mark-diodati/2012/01/15/deja-vu-%E2...
For a thoughtful presentation of both sides, try: http://www.kansascityfed.org/PUBLICAT/econrev/pdf/3q08sulliv...
I think you'll see that it concludes much the same thing as I mentioned the banks (here in the US anyway) conclude: the costs are not worth the theoretical "kinda safer" gains in security.
Security is a nuanced, no-one-solution-fits-all, dynamic, evolving systems engineering problem. The adversaries are smart, but more importantly have common sense (unlike governments and consumers) - they will exploit weaknesses in the weakest link. Replace passwords with smart cards, no problem - they will go after the next link. The (US and EU) banks know this -- they all employ layered fraud and security measures --- despite consumers who may have unquestioning faith in the perfect security of smart cards.
And when you come back in 5 years and payment cards are still NOT being used in the mainstream (US anyway where cost vs. benefit is important), please have the courtesy to up vote.
I mean, that would work, wouldn't it? I suppose for it to work, though, we'd have to have an actual .. you know .. OS Company .. again.
The password is used to access those keys at the identity provider.
Replace the identify provider (idp) by a token. Bang. Much easier than rolling out yet another standard.
The way I can see it working is if there is a private key on the device, inaccessible to the host hardware, and the crypto stuff is done on the device - so the Yubikey was effectively the client. Auth service sends challenge to the browser which sends it to the driver which asks the yubikey wtf, the yubikey responds to the challenge, and the response is sent to the browser and back to the host.
But this would all fall down if there was even the slightest chink and your host hardware could be modified to access/save the keys on all of the Yubikeys when they are plugged in.
I would love to have some other solution but I don't see this as one. I grew up remembering passwords and I'm pretty good at it now.
But if you have something for under my skin, we can talk again.
So which desktop is runs on, or even phone, tablet or any other form factor, is irrelevant.
So they’ve developed a (as yet unnamed) protocol for device-based authentication that they say is independent of Google, requires no special software to work — aside from a web browser that supports the login standard — and which prevents web sites from using this technology to track users.
Well, yes. But you'd hopefully have a master passphrase to open the "smart-ring" device, making theft less of a problem.
then...
"we'd use the token, but for important operations, a password would be asked"
people just don't understand what they write ;)
and then ..." Under threat of a boycott, Intel Corp. backed down slightly yesterday from a controversial plan to add a security feature to its computer chips, but privacy advocates said the change doesn't go far enough to ease their concerns.
Privacy groups fear that the new feature, sort of a Social Security number hard-wired into computers, would be used to monitor Internet users' activities online, allowing companies to collect marketing data on them. " http://news.cnet.com/8301-27080_3-20126770-245/intel-chips-l...
Personally I'll stick to passwords, little by little they will add code and "features" to that usb stick. Call me paranoid but Google has more than enough info on me and what I search /ed for.
However why oh why on earth is the YubiKey challenge/response optional?
Why can that thing work in a mode where it simply "dumps text"?
It's terrible that it's optional because it means that I cannot be sure in which mode that thing is operating right!?
But I love the idea: we need more physical tokens doing challenge/response and less "let me store this in my phone's 'master app of all the passwords'" snake oils.