I've been thinking a lot recently about information security and passwords. It's widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I've seen, short of client-side certificates, both require a trusted third party and provide little auditability.I'm working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device ((iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons)) (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request.
So far, I've written a small Django server application, and a Python CLI device and client. They're not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I'll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator.
This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions.
On the other hand, I'm no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I'm going to release this (as I plan to once I get something working), I need a name. Ideas?
I'd suggest having the request signed by the server when it is sent so the handheld device can (somewhat) validate the origin. Might also make it useful to (optionally) require a password to say "yes" or "no" on the mobile device.
ReplyDeleteIs this goingto use SMS for transport to the device, or IP? If it were possible to choose one or the other it would be nice. I have a server on my network (Multitech iSMS) with a cellular radio on it that I can use to send SMS messages directly. Being able to use that would be nice.
Also, if it hasn't been used, I'd call it Janus. :D
+1 for authenticating the transaction.
ReplyDeleteA unique nonce is essential. A sequence number will work well but it's very important that the server ensure it is never repeated.
@qhartman: The request is signed by the server and encrypted with the device's public key. I'm using HTTP via IP, but there's no reason it couldn't use SMS. (other than latency)
ReplyDelete@Edward: Yeah, it's a sequential transaction ID.
Uhhhh, no way am I going to trust Apple/Google/$carrier.
ReplyDeleteBanks around here (Czecnia) usually send one-time password over SMS. It's simpler in that any (non-smart) phone will do, but it requires ability to send SMS from the server (for which there does not seem to be any web service anymore at least here, so it'd probaby need GSM modem).
ReplyDeleteTake a look at what myopenid.com does. When I log in I get a call asking for me to confirm my identity.
ReplyDeleteThat sounds a lot like my sido prototype. It's proof-of-concept of a safer sudo. As normal user you can add commands to a queue. Then you switch to a secure VT to sign those and finally give the signed commands to a privileged helper that verifies and runs it.
ReplyDeleteMore notes are at http://iki.fi/lindi/darcs/sido/README -- I am currently trying to figure out an unspoofable way to show text to user under Xorg, switching to another VT just does not cut it in the modern desktop age (it looks ugly to the user and is crashy).
I agree with Luke!
ReplyDeleteThere are some work done where they uses Jabber/XMPP to do this. The thing is not to use the same path as you read/login with. XMPP != HTTP which is a good thing. So send a message to a users XID from the server with a key that should be entered into the web browser. No JavaScript fooling you then.
ReplyDelete