Hi Zed, I had this idea recently which might somehow be related to yours (or complement it, to be more precise).
I was thinking about making various password managers (KeePassX, etc.) work better with web sites and about
storing your passwords on your mobile device and use this device to easily log into services (for example
when you're away from your PC). So the idea was basically this:
- show me a 2d barcode (QR-code, datamatrix, whatever) on your Sign-in page;
- I scan this code with my mobile phone application (or simply use desktop application that takes a screenshot);
- this application (password manager) makes a request to your service and authenticates me (using SRP);
- your Sign-in page uses AJAX in the background to check if I'm already authenticated;
- if the auth process was finished - I'm redirected to login-only area of your site;
So this 2d barcode would contain some kind of nonce that would uniquely identify current Sign-in
page (we obviously can't use cookies because we're using different channels).
This whole idea could also make sign-up process much more simple (you could, for example,
encode password requirements for your site, and my password manager would automatically
generate the password according to these requirements, and would sign me up and record
credentials in itself).
Just an idea. I'm not sure if it's viable at all (there might be some hard-to-overcome security issues),
it would be nice if you let me know what you think about it.
I'd have to look at it more, but I think doing the 2nd factor auth before a simple password auth will have problems. What you really want is they login like normal, but then they get a txt message or use an app on their phone to do the 2nd factor.
2 factor auth though is very much possible with this, actually with any service. I may try to hack that up as a demo this week. Maybe use twilio for it and have it call you. Fun!
I wasn't thinking about second factory actually (unfortunately I can't easily express my ideas in English, I haven't made it clear enough). The barcode would make a first (and only) factor. Of course username/password would stay there for backwards compatibility.
Once again, I'll try to express myself more clearly:
- we show a username/password input boxes and 2d barcode (QR/datamatrix);
- the user may simply enter his username/password and then everything works your way;
- he may also choose to use some kind of password manager that is compatible with this protocol;
- this password manager scans the code and performs full SRP authentication on the above URL; if it's successful we simply send some kind of notification to your service - or you poll our service for the result;
- if the result is OK we simply set session data in the cookie as usual and from now on the user is authenticated;
This has additional advantage of the actual crypto going on in the password manager and on the server. It also gives the possibility to perform the sign-up process semi-automatically as well (think of password generation - the user doesn't have to know it at all). And then think of public wifi or other networks you don't trust: you may perform the auth via GSM using your mobile. But the biggest improvement, in my opinion, is the usability aspect. You could have your password manager lying in the background and when you are shown a login page you could simply double-click an icon in your tray area and you are immediately logged into the app. Or you could use password manager on your mobile phone to take a shot with its camera.
Comments
Hi Zed, I had this idea recently which might somehow be related to yours (or complement it, to be more precise). I was thinking about making various password managers (KeePassX, etc.) work better with web sites and about storing your passwords on your mobile device and use this device to easily log into services (for example when you're away from your PC). So the idea was basically this:
- show me a 2d barcode (QR-code, datamatrix, whatever) on your Sign-in page;
- I scan this code with my mobile phone application (or simply use desktop application that takes a screenshot);
- this application (password manager) makes a request to your service and authenticates me (using SRP);
- your Sign-in page uses AJAX in the background to check if I'm already authenticated;
- if the auth process was finished - I'm redirected to login-only area of your site;
So this 2d barcode would contain some kind of nonce that would uniquely identify current Sign-in page (we obviously can't use cookies because we're using different channels).
This whole idea could also make sign-up process much more simple (you could, for example, encode password requirements for your site, and my password manager would automatically generate the password according to these requirements, and would sign me up and record credentials in itself).
Just an idea. I'm not sure if it's viable at all (there might be some hard-to-overcome security issues), it would be nice if you let me know what you think about it.
I'd have to look at it more, but I think doing the 2nd factor auth before a simple password auth will have problems. What you really want is they login like normal, but then they get a txt message or use an app on their phone to do the 2nd factor.
2 factor auth though is very much possible with this, actually with any service. I may try to hack that up as a demo this week. Maybe use twilio for it and have it call you. Fun!
I wasn't thinking about second factory actually (unfortunately I can't easily express my ideas in English, I haven't made it clear enough). The barcode would make a first (and only) factor. Of course username/password would stay there for backwards compatibility.
Once again, I'll try to express myself more clearly:
- we show a username/password input boxes and 2d barcode (QR/datamatrix);
- the user may simply enter his username/password and then everything works your way;
- he may also choose to use some kind of password manager that is compatible with this protocol;
- in this case we encode some data in the barcode (it could be some login URL, e.g. https://example.com/srp/yourservice.com/?nonce=some_random_n...);
- this password manager scans the code and performs full SRP authentication on the above URL; if it's successful we simply send some kind of notification to your service - or you poll our service for the result;
- we check the result on the actual login page as well (e.g. using AJAX): we may simply poll some other URL, like: https://example.com/srp/yourservice.com/result/?nonce=the_sa... (of cource results signing/etc. comes into play here);
- if the result is OK we simply set session data in the cookie as usual and from now on the user is authenticated;
This has additional advantage of the actual crypto going on in the password manager and on the server. It also gives the possibility to perform the sign-up process semi-automatically as well (think of password generation - the user doesn't have to know it at all). And then think of public wifi or other networks you don't trust: you may perform the auth via GSM using your mobile. But the biggest improvement, in my opinion, is the usability aspect. You could have your password manager lying in the background and when you are shown a login page you could simply double-click an icon in your tray area and you are immediately logged into the app. Or you could use password manager on your mobile phone to take a shot with its camera.
I hope this time it's clearer.
Hmmm, yeah that's possible, but I'd have to actually implement it and then try to hack it before I could give it any kind of blessing.