Since the Twitter breakin I’ve switched from using only three different passwords for my dozens of online accounts to using a different randomly-generated password for each site.
The problem of course is how to keep track of all these different passwords.
There are some apps like 1Password and KeePass that will generate random passwords for you and auto-fill web forms by integrating with your browser. Some of these password managers have mobile phone versions, so when you go to another computer you can retrieve your password from your phone and type it in by hand. The passwords are encrypted on the phone and you have to tap out a master password to access them.
Today at lunch I was thinking it would be cool if the password managers could make use of the webcams that almost all computers have now. So instead of typing this really long string of random characters, I could just hold my phone up to the webcam and it would read a datamatrix or semacode off the phone and autotype the password that way. This could even be done using Flash to read the webcam.
Or better still, the website could issue a challenge to the phone which it would respond to with a barcode, so that someone taking a picture of your phone wouldn’t be able to intercept your permanent password.
I’m sure it’s possible to improve on these specific ideas, but t’s clear to me that mobile phones will serve as security tokens for many, many services. Airlines are already testing “mobile ticketing” which is basically a barcode you display on your phone.
It’s true that phones aren’t as tamper-resistant as professional security tokens in use today, but phone authorization is a big improvement over using the same password for all your websites.
Posted on 12 October 2009
- Leave a comment
- Subscribe with Google Reader
- Follow me on Twitter
Did you like this article?
-
Or better still, the website could issue a challenge to the phone which it would respond to with a barcode, so that someone taking a picture of your phone wouldn’t be able to intercept your permanent password.
If this is a nearly instantaneous challenge, you could simply generate a one-time password and SMS it to the user. As long as the password is valid only for a short amount of time (say, 30 minutes), that offers pretty good security while avoiding the need for a permanent password altogether. No barcode necessary.
-
That is a really nice idea.
-
SMS one-time passwords are commonly used in internet banking in the Czech Republic’s banks. Timeout is usually 10 minutes.
-
I just remembered that my wife gets one-time passwords for her bank via SMS also. Great in general, but it was a problem when we were in Bora Bora and SMS wasn’t working on her phone.
-
-
-
I think Google already does this for certain account verification procedures. It also works as a better captcha alternative, since phone numbers are a lot more difficult to come by than email addresses / captcha-solvers.
The only downside is cost I suppose… until somebody puts an end to the ridiculous sms charges mobile carriers have.
-
Actually as I’m thinking about this, this is perhaps slightly less secure than having your passwords encrypted on your phone, or a simple challenge/response system on the phone.
With an encrypted password store, you have to tap out a master passcode to unlock the passwords.
But my phone (iPhone) will display an SMS even if the phone is locked, so all you need is physical possession of my phone to get my OTP via SMS. And you don’t need to know a special passcode to unlock the password store.
-
The attacker who has stolen your phone also needs to know the site that you’re using and your username. A good OTP implementation wouldn’t give either of that information away.
-
Thinking about this some more, you could maybe still do it via SMS with the help of an app on your phone to help fix the display-OTP-even-while-locked problem.
If the phone and the service share a one time pad, the password that is SMS’d to you could then link to an app which would decrypt it to the true code which you’d type into the app. Maybe too many steps, though.
-
One problem with the SMS approach is that security of GSM is pretty weak. I think the only reason that there have not been any widespread attacks against GSM is that there are no free open-source implementations and thus nobody has played around with it enough. But that’s changing. There’s already basic GSM basestation support for GNURadio (http://gnuradio.org/) and people are actively working on rainbow tables allowing to crack the A5/1 encryption scheme used in GSM (http://reflextor.com/trac/a51).
I think in a short time from now we can expect the same security from GSM as we can expect from WEP. While the encryption used in the newer UMTS protocol is pretty secure, it’s still possible to force phones to downgrade to a GSM connection by disturbing the UMTS frequencies with your own emitter.
-
-
-
Another idea:
Bluetooth seems to be falling out of fashion, but if your phone was physically close to your computer and both were bluetooth enabled, you could have some token on the phone sent to the browser to avoid the need for the user to enter anything in at all. Maybe you could do the same with wifi using Bonjour.
-
Patentable.
-
Nice idea Nat. The SMS one is also something i have heard before – works well so long as you’re in your own country… international SMS can be a nightmare (what is the country code etc – stuff i don’t wanna have to know). An image is easy.
Semacode could also be useful offline due to the data it can hold.
-
It also works abroad if you have roaming turned on and your SIM card with you.
-
Ah cool – need to get out more!
Was thinking of those apps that say “Enter your mobile number” and then asks you to select your country and so on – a bit of a pain, that’s all.
Actually i never remember my mobile number anyway so the SMS option would never work for me in any case
-
-
-
This can me used not just for passwords, but for financial transactions too.
Coca-cola has been doing that in Japan since 2001 with their C-mode vending machines.
-
I’ve been trying to use a program on my iPhone (CardStar) to replace my affinity cards at grocery stores. It’s the same concept—the barcode displays on the screen and I have it scanned at the store. But it doesn’t work. I’ve tried it in two different grocery stores, and despite valiant effort on the part of the clerks, the bar codes have proven unscannable.
No doubt it’s possible. After all, no sane person would release a program that cannot possibly function. But apparently it’s so finicky as to be impractical, at least in my limited experience.
-
Yeah, it doesn’t make sense to me that the reflective properties of the pixels would change enough to be picked up by those red-laser scanners. Probably would be more likely to work with a CCD reader.
Also, my experience is that there are a lot of non-working apps for the iPhone. The other day I bought the “sonar ruler” app which uses little clicking sounds to try to guess the distance to an object. It doesn’t work at all. Likewise the heart rate app that suggests you press the phone against your chest so it can hear your heart beating.
-
98% of all iPhone apps are games, flashlights, alarm clocks, and levels, it would seem. But I do want to point out that Starbucks has a “gift card” type app for the iPhone and they’re currently testing it at 16 locations in the valley and somewhere else to let you pay. It does it by generating a barcode that the cashier scans off your iPhone screen. Which makes me wonder if their testing is limited like that because they had to roll out special scanning hardware, or if they are using their normal stuff and it’s for other reasons.
And you should be able to *lay* the iPhone on your chest and get heartrate using the accelerometer instead of trying for sound. But it wouldn’t surprise me that there’s a sucky app that doesn’t work at all for that. It is also worth noting, however, that apparently Nike is working on a real heart rate monitor that will talk to the newer generation iPods that have Nike+ capability.
-
-
Here in Spain there are experiences on using bidi codes on mobile phones by Vodafone and the Spanair airline: http://www.movilfonia.com/noticia.asp?ref=4278 (Spanish)
-
-
One way to implement this would be to do so as an OpenID provider. That way, you could use existing OpenID support to link to your provider. Your provider could then use this method (however your work it out) to be either the sole authentication factor, or as a 2nd factor to go with a password.
(Your original post reminded me lot of the one-time-password (OTP) applications that I used to see for PalmOS…)
-
This is a great idea, but I think the underlying problem is not a technical one, but rather that there are no “real” penalties for bad security, that the existing social construct is to hold people accountable after the fact rather than secure things before, and therefore people don’t care about good security. Talk to basically any security researcher and I think you’ll hear the same.
Take, for example, the credit card system. The industry has spent billions of dollars rolling out RFID infrastructure, more formally called “contactless smartcard”. This could have been done as an end-to-end challenge/response between the issuer (or at least clearinghouse) and the card, making it impossible to fake or replay transactions.
Instead, it sends your credit card number (shared secret) plaintext over the wireless channel.
-
That is so bad. Ditto the RFID passport situation. I’m not much of a security maven but these kinds of decisions defy reason.
-
-
It all depends on how far you want to go with the security. If “enough” is just to separate the password from the phone itself, how about printing your barcode password and keeping it in your wallet? Then use the camera on the phone to “scan” it when necessary. Add a mental password layer to “unlock” the barcode password and you’re back to one thing to remember and TWO things someone would have to steal and crack. With a 3D barcode you can embed a good amount of data in there to unlock, too.
-
what about http://www.clipperz.com? no local apps, no webcams, no flash, no phones, just client side encryption inside the browser with javascript and online (or offline) storage of the encrypted data.
-
i heart clipperz
-
-
Seems your looking for something like our QR-TAN approach described here: http://gst.priv.at/papers/ares09_qrtan.pdf (disclaimer: I’m one of the authors). QR-TAN is basically targeted for online banking transactions, but could also be used for other purposes (e.g. simple logins to a website).
27 comments