A Method for Password-Less Authentication(h4ck.guru)
h4ck.guru
A Method for Password-Less Authentication
http://www.h4ck.guru/passwordless.html
30 comments
> Using smart phones as authentication devices suffers from this exact same problem.
This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available.
> I have concluded the password is king.
What about the keypairs?
They are the same as passwords (when done right) - just long "random" strings of data. However, they don't have to be transferred over the wire for everyone to see. And they're more flexible in terms of possibilities on security-convenience spectrum.
There is no SRP standard for web (JS crypto doesn't count), but almost every TLS-aware system (client or server) out there has support for client certificates. The only problem is that browser vendors genuinely hate this (and want to shove users their own inventions), but if someone could somehow persuade them - it would just work.
This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available.
> I have concluded the password is king.
What about the keypairs?
They are the same as passwords (when done right) - just long "random" strings of data. However, they don't have to be transferred over the wire for everyone to see. And they're more flexible in terms of possibilities on security-convenience spectrum.
There is no SRP standard for web (JS crypto doesn't count), but almost every TLS-aware system (client or server) out there has support for client certificates. The only problem is that browser vendors genuinely hate this (and want to shove users their own inventions), but if someone could somehow persuade them - it would just work.
> until the phone melts down
Under what circumstance would that be considered normal, expected, or acceptable?
My phone just doesn't do that, and never has. Sure it crashes maybe once a month or so, but then I'm able to use it again within ~15 seconds.
I think that experience is mirrored by most people.
Under what circumstance would that be considered normal, expected, or acceptable?
My phone just doesn't do that, and never has. Sure it crashes maybe once a month or so, but then I'm able to use it again within ~15 seconds.
I think that experience is mirrored by most people.
We have different experiences, then.
Monthly crashes are no big deal (in fact, I think, my phone crashes only once in a few months). Slight nuisance at most - e.g. if the crash corrupts Android app cache and system boots awfully long minutes, re-compiling the apps. However, I have three different mobile devices (2 phones and a tablet), from different vendors (Nokia, Acer, Samsung) that had suffered a hardware failure after some (5-8) years of use. Three dead eMMCs.
So, I'm sort of wary. It's exceptional, infrequent but happens quite unexpectedly and is very frustrating when it does. Especially if the recovery keys (which are rarely accessed by design) are lost, inaccessible (you're on the road) or misplaced.
Monthly crashes are no big deal (in fact, I think, my phone crashes only once in a few months). Slight nuisance at most - e.g. if the crash corrupts Android app cache and system boots awfully long minutes, re-compiling the apps. However, I have three different mobile devices (2 phones and a tablet), from different vendors (Nokia, Acer, Samsung) that had suffered a hardware failure after some (5-8) years of use. Three dead eMMCs.
So, I'm sort of wary. It's exceptional, infrequent but happens quite unexpectedly and is very frustrating when it does. Especially if the recovery keys (which are rarely accessed by design) are lost, inaccessible (you're on the road) or misplaced.
My phone rarely crashes too, but the point is it tends to crash at the worst moments (perhaps all moments are the worst moments, when you are reliant on technology).
Using strong passwords and an auto-completing app like keepass, this is simply not an issue. I can log in from another device.
Also, reliance on mobile devices means reliance on some corporation's cellular network. Putting the control of your vital access into the hands of people who you know are not your friends and who would love to take more than just your money is never a good idea, in my opinion. When their system crashes you can't just reboot your phone to fix the problem, you can't do anything.. in fact. You have to sit and stew in the hell of your creation until their system magically comes back online. Not worth it.
Using strong passwords and an auto-completing app like keepass, this is simply not an issue. I can log in from another device.
Also, reliance on mobile devices means reliance on some corporation's cellular network. Putting the control of your vital access into the hands of people who you know are not your friends and who would love to take more than just your money is never a good idea, in my opinion. When their system crashes you can't just reboot your phone to fix the problem, you can't do anything.. in fact. You have to sit and stew in the hell of your creation until their system magically comes back online. Not worth it.
> 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available.
Get a Yubikey and store all your OATH tokens on that, as well as your phone.
Get a Yubikey and store all your OATH tokens on that, as well as your phone.
> Get a Yubikey
Easier said than done. Import restrictions on any cryptographic devices in the country I live. :( Russian government genuinely hates civil cryptography.
Last news I've heard, late this spring, some company had managed to negotiate and obtain the necessary certifications and permissions, but they're still setting warehouses and logistics.
Thought of getting an ATECC508A or alike Secure Element IC and make a DIY HSM, but had no luck either. An acquaintance why runs an electronic component retail business said he'll try but these are rare find here, and usually out of stock.
(I wonder if there's a way to buy a Yubikey or Nitrokey token, visiting EU as a tourist... Customs probably won't care checking what some USB stick in luggage is - everyone has flash drives.)
Easier said than done. Import restrictions on any cryptographic devices in the country I live. :( Russian government genuinely hates civil cryptography.
Last news I've heard, late this spring, some company had managed to negotiate and obtain the necessary certifications and permissions, but they're still setting warehouses and logistics.
Thought of getting an ATECC508A or alike Secure Element IC and make a DIY HSM, but had no luck either. An acquaintance why runs an electronic component retail business said he'll try but these are rare find here, and usually out of stock.
(I wonder if there's a way to buy a Yubikey or Nitrokey token, visiting EU as a tourist... Customs probably won't care checking what some USB stick in luggage is - everyone has flash drives.)
Ah, that sucks :( Does your mail carrier care what's in the envelope? A Yubikey is very small, or you can buy one of the Fidesmo cards, if you want to be lower-key.
Mail carrier doesn't[1], import customs do. They tend to regularly deny various hardware, like phones that aren't certified in Russia (I've tried to buy an OpenMoko GTA01 and it haven't passed through) or sometimes random hardware that has crypto or wireless stuff in it (e.g. Steam Link set-top-boxes).
I'm not sure what sort of logic they use for screening. They'd probably let anything pass if it'd be declared as "USB flash drive" and shipped from China (tons of such stuff is bought on AliExpress every day) in a typical envelope, haha - but may well likely screen the parcel for less common cases.
___
[1] A counter-terrorism^W mass surveillance law had recently passed so they will have to start screening parcels in 2017, though - but that's another story.
I'm not sure what sort of logic they use for screening. They'd probably let anything pass if it'd be declared as "USB flash drive" and shipped from China (tons of such stuff is bought on AliExpress every day) in a typical envelope, haha - but may well likely screen the parcel for less common cases.
___
[1] A counter-terrorism^W mass surveillance law had recently passed so they will have to start screening parcels in 2017, though - but that's another story.
Oh, that's unfortunate. You're right about China, they're very savvy about marking things as "camera accessories" and "usb flash drive" so pretty much everything passes through, too bad other companies don't do that too...
I like keypairs but if you work with a lot of devices, it can be a bit troublesome managing all the per-device keys. I find passwords are a bit easier, this may be a matter of personal preference.
In the can-you-really-use-cell-phone-for-trusted-computing department:
I have had support agents come to me and say, "This user was convinced to put his phone into developer mode and attach it to a computer running malware controlled by the attacker." Game over.
Okay, that is colossally stupid behavior. Unbelievable, to most of the audience here. But users will do the damnedest things, and platforms -- whatever their static security failings -- really need to be resilient against coerced or ill-guided user actions as well.
I've worked on platforms that have had very well designed security systems, but they also made very sharp distinctions between what could be done by a developer and a normal user, and for the most part those worlds did not intersect at all.
Android's barrier of "tap seven times here and you're a developer" is very low. It's clever, and good for many reasons, but user security isn't one of them.
I have had support agents come to me and say, "This user was convinced to put his phone into developer mode and attach it to a computer running malware controlled by the attacker." Game over.
Okay, that is colossally stupid behavior. Unbelievable, to most of the audience here. But users will do the damnedest things, and platforms -- whatever their static security failings -- really need to be resilient against coerced or ill-guided user actions as well.
I've worked on platforms that have had very well designed security systems, but they also made very sharp distinctions between what could be done by a developer and a normal user, and for the most part those worlds did not intersect at all.
Android's barrier of "tap seven times here and you're a developer" is very low. It's clever, and good for many reasons, but user security isn't one of them.
It is clear that user is the biggest risk in all systems, but that doesn't quite take away from the more important addressable question - specifically - is a password-less method better than what we do today (aka passwords.
I'd take a hunch that the number of users with easily guessable passwords outweighs the number of targeted malware attempts.
But I need not guess, any of the password dump files provides a good statistic showing % of passwords.. what was it something like 0.6% are still 123456? and another 2-4% some similar-looking cousin?
If we go with this logic - we also wind up getting extra wins: better usability, and cheaper to deploy/manage. But that's a whole other topic.
I'd take a hunch that the number of users with easily guessable passwords outweighs the number of targeted malware attempts.
But I need not guess, any of the password dump files provides a good statistic showing % of passwords.. what was it something like 0.6% are still 123456? and another 2-4% some similar-looking cousin?
If we go with this logic - we also wind up getting extra wins: better usability, and cheaper to deploy/manage. But that's a whole other topic.
Recently I've moved around a bit and have been connecting to a lot of different networks for my internet. My online bank account has flagged and reset my account about a half dozen times in the last month.
The strategy seems to be "There is a snowball's chance in hell the account was compromised let's just lock online access and require a password reset just incase".
It's inconvenient, but you have to wander at what point do you need to take control from the user. It's hubris to think we can imagine all the edge cases for user behavior (like you described).
The strategy seems to be "There is a snowball's chance in hell the account was compromised let's just lock online access and require a password reset just incase".
It's inconvenient, but you have to wander at what point do you need to take control from the user. It's hubris to think we can imagine all the edge cases for user behavior (like you described).
It looks a bit like Steve Gibson's SQRL (which uses QR code rather than bluetooth), which I think is an excellent idea. I just wish it was sponsored by someone more consensual/followed by the tech community.
But the idea of saving a private key on a locked down, app whitelisting, disk encrypted device (like an iphone) and to have a protocole that does not rely on a third party (which currently are mostly google and the social networks, the last people on earth I would want to share which sites I login to) is appealing.
But the idea of saving a private key on a locked down, app whitelisting, disk encrypted device (like an iphone) and to have a protocole that does not rely on a third party (which currently are mostly google and the social networks, the last people on earth I would want to share which sites I login to) is appealing.
>It looks a bit like Steve Gibson's SQRL (which uses QR code rather than bluetooth)
or you could combine them: when Bluetooth isn't available then use a QR code
or you could combine them: when Bluetooth isn't available then use a QR code
The bluetooth dependency looka painful. But I'm also highly skeptical of the behavioural analysis. I feel like a piece of malware could replay recorded behaviour and attack at 2:30am when the user is probably close enough to trigger an automatic authentication.
Since agents need to be authenticated once with users, the replay vulnerability should not be a concern. But a malware that sits on a client and potentially can access to agent keys can definitely be used to authenticate when phone is in proximity of infected machine. But that level of vulnerability on clients is pretty serious.
Well, if its your home computer and you know a target uses this method, then you know they've authenticated their agent. Maybe someone cleverer than I can come up with an attack vector starting with an unauthenticated agent, but I'll ignore that for now.
And I'm not talking about root access here. Just userspace to record mouse and keystrokes and then replay that. Then, just a couple of clicks and letters changed to some service that uses this authentication. If the replay is done right, those couple of clicks might lower the confidence of the behaviour analysis but not enough to lock it up (that sort of sensitivity would just make it infeasible). Now that it is authenticated, it can stop pretending and quickly move the mouse around and type to do whatever it wants. maybe it downloads your emails and uploads them somewhere.
The point is, your method requires no interaction for the majority of authentications and is potentially always online.
And I'm not talking about root access here. Just userspace to record mouse and keystrokes and then replay that. Then, just a couple of clicks and letters changed to some service that uses this authentication. If the replay is done right, those couple of clicks might lower the confidence of the behaviour analysis but not enough to lock it up (that sort of sensitivity would just make it infeasible). Now that it is authenticated, it can stop pretending and quickly move the mouse around and type to do whatever it wants. maybe it downloads your emails and uploads them somewhere.
The point is, your method requires no interaction for the majority of authentications and is potentially always online.
This sentence worries me: "any secure computation algorithm that can compare our choice of user behavioral signature without exposing it" because it makes it seem as though there are lots of these just lying around. It seems like this would be very tricky to construct, especially given the inherent fuzziness of a signature/fingerprint based on user behavior. Do zero-knowledge 'proofs of behavior' exist?
EDIT: That said, I do think this is a cute idea.
EDIT: That said, I do think this is a cute idea.
I knew someone will catch that. I was a bit sloppy on that sentence :) I will have to improve it.
1- We only need secure multi-party computation algorithm if we cannot trust the server. In cases that server can be trusted with behavioral fingerprints then we can use server to to do the comparison.
2- One can assume that in some cases the server should not know about the behavioral fingerprint. For example in case that this procedure is implemented as a service, it might not be proper to send client side mouse movement and key presses to the server. Still server can be trusted as a mediator but should not know anything more than fingerprints being almost equal. You are right that behavioral finger prints like mouse movement are fuzzy. Specially since agent and browser are running on two different threads they get different time stamps for each mouse location. In this case you have to introduce some acceptance for fuzziness as you mentioned. Some statistical comparison. This is not as easy as checking equality securely (like Socialist millionaires problem) but you can in theory turn any circuit and make it secure so that the circuit will only expose fuzzy equality and nothing more about the data. See secure multi party computation: https://en.wikipedia.org/wiki/Secure_multi-party_computation
But your concern is valid since in practice the computation involved to do secure multi party computation in this case might be demanding for a browser. I have yet to verify that in practice. Keep in mind that our case is a bit more relaxed than general secure multi party computation problem since we have a server that can be trusted a little bit. Maybe that can help us a bit in devising a secure computation scheme. Any volunteers to work on that? :)
1- We only need secure multi-party computation algorithm if we cannot trust the server. In cases that server can be trusted with behavioral fingerprints then we can use server to to do the comparison.
2- One can assume that in some cases the server should not know about the behavioral fingerprint. For example in case that this procedure is implemented as a service, it might not be proper to send client side mouse movement and key presses to the server. Still server can be trusted as a mediator but should not know anything more than fingerprints being almost equal. You are right that behavioral finger prints like mouse movement are fuzzy. Specially since agent and browser are running on two different threads they get different time stamps for each mouse location. In this case you have to introduce some acceptance for fuzziness as you mentioned. Some statistical comparison. This is not as easy as checking equality securely (like Socialist millionaires problem) but you can in theory turn any circuit and make it secure so that the circuit will only expose fuzzy equality and nothing more about the data. See secure multi party computation: https://en.wikipedia.org/wiki/Secure_multi-party_computation
But your concern is valid since in practice the computation involved to do secure multi party computation in this case might be demanding for a browser. I have yet to verify that in practice. Keep in mind that our case is a bit more relaxed than general secure multi party computation problem since we have a server that can be trusted a little bit. Maybe that can help us a bit in devising a secure computation scheme. Any volunteers to work on that? :)
Actually the secure comparison protocol is the easy part - even generic SMC techniques are getting really fast these days. Also, they only involve about as much heavyweight crypto as a few TLS handshakes. Extracting a per-user fuzzy fingerprint from mouse and keyboard movements with enough entropy to make brute-force infeasible might be harder.
We released a passwordless auth library for iOS about 2 weeks ago. At first glance, it looks much simpler than the process described on this website. We also take advantage of Secure Enclave key storage rather than leave the authenticator somewhere that malware can steal.
https://blog.trailofbits.com/2016/06/28/start-using-the-secu...
https://github.com/tidas
https://blog.trailofbits.com/2016/06/28/start-using-the-secu...
https://github.com/tidas
Reminds me of the Biometric Open Standard.
Link to draft: official one is behind paywall https://www.oasis-open.org/committees/download.php/56664/P24...
Link to draft: official one is behind paywall https://www.oasis-open.org/committees/download.php/56664/P24...
> Open Standard
> behind paywall
> behind paywall
Everything looks great, except for bluetooth. Can't we use internet instead.?
Something like this https://m.youtube.com/watch?feature=youtu.be&v=YRL0u61dLnM
This is what I use when logging in to the state run bookmaker/lottery company in Norway. Works great. I just type in my SSN and I will get a notification on my iPhone. The solution is delivered by Buypass[0].
[0] https://www.buypass.com/?_ga=1.237154944.1017563517.14669318...
[0] https://www.buypass.com/?_ga=1.237154944.1017563517.14669318...
My bank, Skandiabanken,sends an ordinary SMS message so it works with any mobile phone including dumb phones. To compromise it someone would have to know my personnummer and steal my mobile. Skandiabanken also gives me a scratch card one time pad so that I can log in without the mobile, the web page asks for the n-th number from the card.
NFC would mitigate the "close enough to trigger" attacker
Anyone who's spent time in hotels in recent years knows that since switching from mechanical keys to magnetic keys, sometimes the keys break and the guest is locked out of their hotel room, which of course they never discover until trying to open the door. Then they have to go to the front desk, probably stand in line, and request a replacement key.
Using smart phones as authentication devices suffers from this exact same problem. I can't speak for iOS but every android phone I've had has experienced slow operation, crashes, and other kinds of issues at inopportune moments. When I am trying to log into something to perform a 5 minute task I don't want to be delayed for 15 minutes while my phone chugs away at whatever.
I'm just one geek, but I have spent a lot of time thinking about "alternatives to passwords". I have concluded the password is king. We use passwords everywhere, and we will continue to use passwords everywhere, until someone invents something better. In 100s of years nobody has done that yet (Mechanical keys are a kind of password).
Instead of trying to replace passwords which are reliable and simple to use, with complicated authentication systems which are not reliable and not simple, we should focus our efforts on improving password authentication in our existing apps (no more limitations), building great password tools like keepass.info, and encouraging the average user to use password tools and practice good password habits.