Google's Authentication Research

Google is working on non-password authentication techniques.

But for Google’s password-liberation plan to really take off, they’re going to need other websites to play ball. “Others have tried similar approaches but achieved little success in the consumer world,” they write. “Although we recognize that our initiative will likewise remain speculative until we’ve proven large scale acceptance, we’re eager to test it with other websites.”

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.

The great thing about Google’s approach is that it circumvents the really common attack that even Google’s existing mobile-phone authentication system can’t prevent: phishing.

They have enough industry muscle that they might pull it off.

Another article.

Tags: , , ,

Posted on January 22, 2013 at 12:04 PM • 52 Comments

Comments

B. Johnson • January 22, 2013 12:42 PM

I’m a little skeptical of the idea. Only requiring a password for major account changes and relying on a physical token for standard access seems to me like the reverse of what it should be. The fact that you could unknowingly lose (or have stolen) the token for any length of time before noticing means that someone could wreak havoc in the mean time. With a password as the “first line” you know that nobody would ever be able to get that without you knowing (i.e. telling them).

Realistically I think that password + challenge-and-answer token would be the way to go, especially since that the people that are screwing up passwords out of ignorance or laziness are going to screw up anything else for the same reasons.

“..a common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”

T. Zucker-Scharff • January 22, 2013 12:59 PM

I’ve been having a debate online (twitter) about hardware authentication methods. I truly believe this is the way to go. I also believe that a hardware token is far better than a challenge answer token, for the same reason I dislike the use of passwords – too many ways to misuse them. I personally use multiple authentication methods when at all possible. For me this means, on some sites, a login name, password, phone number (cell), the phone then needs to be unlocked and the secure messaging system needs its own password, then the 6 digit sequence is entered into the website – which forgets everything once the browser is closed.

BTW, I love the quote B. Johnson has at the end of his comment.

Otto • January 22, 2013 1:02 PM

I think the problem with requiring a physical device (like a USB key) for access is that the device will invariably simply be left in the primary machine at all times. Instead of keeping the device with them for multiple device usage, people will simply acquire as many keys as machines they have and leave them attached at all times.

People are lazy. This is a critical factor in creating a security system. Notice that post-it-note-passwords are commonplace.

Natanael L • January 22, 2013 1:31 PM

My idea: Smartcard with NFC, e-ink display, capacitive touch input (touch screen or fixed keypad?), and since smartcards are 1/3 the thickness of those tiny USB memory cards, you fold one of the ends in a Z pattern to make it a USB plug (the remaining part that sticks out gets folded in under the card)
Now you have a yubikey Neo+smartcard (with USB adapter)+USB token+OTP security token and more.

We have the technology to do it. It’s just a question of getting it done, and done right.

Christian Koch • January 22, 2013 1:55 PM

First of all, minus points for Wired for titling the article the way they did. Why must everything be a “war?”

Second, what is “the login standard” mentioned? HTTP Basic and/or Digest authentication? HTML forms? Is it session-based, cookie-based?

Third, apparently Google hasn’t considered plain vanilla public-key cryptography as an option?

Stephan Engberg • January 22, 2013 2:07 PM

No thank you – hardware is ok, but one key, one purpose and with 100% client-side control. And Google would be the last to know how to link these.

Angus S-F • January 22, 2013 2:14 PM

My biggest problem with these sorts of devices is that it ties all your online activities to one thing, making you trackable across sites. Right now I can create a different account at each site and they can be kept separate.

Steven Hoober • January 22, 2013 2:23 PM

I cannot think of a reason I would carry this with me. Years ago I stopped carrying grocery store discount cards, for example.

No tablet (iPad) or mobile handset has a suitable USB connector. No, I am not going to carry a bunch of dongles for this either. This is non-trivial, in a world on or past the tipping point of more traffic from mobiles.

My keys (home, car) are routinely not under my direct control, but clipped to a briefcase or in a basket at home. Because they don’t work without moving the key to the specific item it enables. Arbitrary people don’t know where I live or what I drive. If you look up my address, you still need to go way over there. None of these are as true for internet access.

Ben • January 22, 2013 2:28 PM

I think a physical break in to secure your security keys, even if they do leave the key in the machine all the time, is going to be preferable to your passwords being lost or cracked. Especially since you could require that new computers be authenticated with the key through some third channel. We’re getting into the sort of realm where it’s just going to be more trouble than it’s worth.

Petréa Mitchell • January 22, 2013 2:45 PM

How do you securely get the physical token?

Does the cryptographic system require the existence of a master key of some sort (like, say, HDCP)?

How do you show that you need a new token for your computer because the old one was lost or compromised? (Or, in other words, how hard will it be for an attacker to get a new token in your name and then pretend for it to be you?)

Will the tokens use a proprietary standard that will take big bucks to license?

Can the standard even allow for multiple token manufacturers?

If this gets popular and suddenly every major Internet company wants to offer their own version, what then? (I’d bet on market share winding up roughly mirroring the shares for whoever’s selling general-purpose computers to end users at that point, since you’ll probably get a situation where the token for a PC or mobile device is packaged with it to make sure you use the manufacturer’s preferred one.)

Peter • January 22, 2013 2:56 PM

@Steven: Google could design the system such that your card is bound to a specific computer (or computers). Adding a new computer would then be an involved process that requires strong proof of your identity. That way, criminals couldn’t simply grab your card and then log on from anywhere.

keypad • January 22, 2013 3:08 PM

@Natanael L: “capacitive touch input”

In a previous discussion about smart-card encryption, it was evident that the passphrase should be typed on the dongle (out of reach of keyloggers).

A dongle without keypad would still fulfill google’s need to uniquely identify people. But it would allow any virus to use the dongle without your consent.

@Natanael L: “e-ink display”

Indeed, a display to display the amount and destination of money transfer, details about password change, …

@Natanael L: “NFC”

NFC but with a tin-foil removable hat, or better a mecanical kill-switch of the antenna.

keypad • January 22, 2013 3:12 PM

And the ability to store multiple private keys on the device, and to administer their access like RequestPolicy and noscript do in Firefox.

Kai • January 22, 2013 3:16 PM

You know what though? All the while Google are working on this, which technically may be more secure, more and more websites are rolling out Facebook authentication and by the time Google get this to market, fb will have cemented it’s position as the defacto standard.

Every day I’m noticing more and more sites that allow you to sign up, or comment, using your fb login and it’s a simple few clicks. No, it’s not as secure as something like Google are proposing, but it’s here now and it works.

keypad • January 22, 2013 3:18 PM

A possible hardware already exists: the Strata by Metawatch, or the Peeble Watch.

The problem is now to make an OS without bug.

Random Guy • January 22, 2013 4:28 PM

I like passwords. If I want to check on my checking balance, I do it. If my wife wants to, she knows the password. She can do it at any time. Passing off a hardware token would be a show stopper.

My wife loses her keys on a regular basis. I do not relish her being locked out of all of her online accounts that often.

What would she use to authenticate herself to the web site titled “I lost my token, send me a new one”?

Also mentioned by others, I have multiple accounts with many sites. I have one for my personal interactions, one for my job, one for my wife’s job, one for each of several organizations I volunteer with. Does Google really expect me to carry +5 tokens? Do they really expect me to associate one token with 5 accounts that I worked hard to keep seperate?

Nope, don’t like it. Don’t like it one bit.

MingoV • January 22, 2013 4:35 PM

Google advises us to replace password-based security with more costly (and cumbersome) systems because a relatively small number of people had their passwords stolen or cracked. That’s like advising us to replace key-based door locks with costly ID verifying locks because a relatively small number of people had their keys stolen or duplicated.

Kevin • January 22, 2013 5:24 PM

If it is something like Google Authenticator, then you can link multiple accounts to it without leaking any information to any of them, including to Google itself.

If you keep your dongle plugged in, but need to press a button (like a yubikey), then viruses cannot use it.

If the dongle also does Bluetooth, then it works on smart phones and tablets.

I welcome anything which helps against phishing attacks. Passwords suck, not because people use weak ones but because people use the same one on multiple sites, so a hack on some random forum site can be be used to break into your Amazon account. Yes, people on this site use different passwords everywhere , but most people don’t and shouldn’t need to.

Natanael L • January 22, 2013 6:07 PM

Random Guy:

1: Access controls. You could assign limited and easily revokable access to another person.

2: You can have a backup device at home. Also, it could be something like a smartcard (see my concept as described in my post closer to the top). How often do the average person lose their cards? Such as ID card?

3: One token can work for many services, even without making you trackable. Nobody would know it’s the same person even if you used multiple services from one provider.

Ben • January 22, 2013 7:02 PM

@Petrea: “Will the tokens use a proprietary standard that will take big bucks to license?

Can the standard even allow for multiple token manufacturers?”

In the article they’re looking at Yubico. I’d imagine the standard is mostly setting the browser up to work with the key in challenge-response mode.

If they made it a pay-to-use standard, or say linked every account through a google server or something, I can’t see what motive others (browsers, websites, etc) would have to go along with it or why people would believe that google wasn’t tracking you with it (did they pinky promise?)

Kai • January 22, 2013 7:42 PM

@Natanael L – works as in it’s easy enough for my wife to use it and she prefers it to using a multitude of different passwords (even when I’ve shown her how to use the OS X keychain, or set up 1Password)

Secure, well, that’s another issue altogether. It’s as secure as your facebook account…

Aristotle • January 23, 2013 12:29 AM

In Greece, by law you have to keep retail receipts that cover 25% of your income and these retail receipts have to be submitted to the Tax Department with your tax return.

To ‘make things easier for people who can’t be bothered collecting paper receipts for their tax returns’ the Greek Tax Department has launched a kind of ‘credit card’ with a chip that you swipe at the POS when you buy your goods that instead of sending info to the credit card company sends it to the Tax Department. Information so far sent includes unique tax roll identifier, location (store id), time stamp for purchase and amount purchased (so far it doesn’t seem to include a detailed breakdown of your purchases). (No this isn’t paranoid fantasy; it’s real. At the moment it’s a voluntary program.)

By law transactions over a certain relatively low amount must be by bank instrument (say, electronic transfer or paper check), not cash. IKEA will not accept cash for purchases over 300 Euros approx.

To bring funds over 14,000 Euros into Greece by electronic bank transfer you need to have a certified copy of the contract or other agreement on file at the bank to support the legitimacy of the transfer.

Can you imagine what would happen–where things would go–if every citizen was obliged to have a token with a unique identifier?

Paolo • January 23, 2013 1:09 AM

Google won’t pull it off for the mere reason that we are dealing with people’s view that we are small meaningless uninteresting for everyone but ourselves. that is why most of us still use the password 123456 in most cases…

Na Me • January 23, 2013 2:39 AM

I’m not going to give google my info. They turn “Think of the passwords” into “think of the children”. They already insist on giving them your phone for recovering email passwords, they already insist on giving your real name. Remember shitstorm over blizzard Real ID when they wanted to use names on forums instead of nicks? Google pulling it on youtube.

Zeus • January 23, 2013 3:54 AM

assume a physical token like yubico to make time based OTPs or some other designs is completely secure but what if user just lose the token ? what if it get damaged ? now to access your cpanel or any other website they must put “i lost my token” instead of “i forgot my password” to buy a new token and register your new token’s serial number there. this recovery will be protected by a security question , SMS etc which google already said is not even secure against phishing. (problem of most of security guys is they just think about current design not future attacks in real life)

Danny Moules • January 23, 2013 5:30 AM

I own a Yubico for one curious feature. It can act as a USB keyboard, automatically dumping a string of text in to a password field. Ideal for creating extra-long encryption keys for TrueCrypt (when supplemented with a traditional password). Was never really that piqued by its ‘main’ features, though it would serve as a handy second factor.

NZ • January 23, 2013 7:28 AM

I used to have a DIY system that worked almost like that : a tiny USB stick (just a bit longer than that Yubico device in the article) + portable KeePass + long random passwords. Then I lost the USB stick. I had a reasonably fresh backup (so I still had my most of my passwords) and a paranoid master password for Keepass (so the passwords were secure), however, that was a mojor hassle. I reverted to old remember-your-password scheme 🙁
I agree both issues (regaining access and securing it) are severe if one uses a hardware token.

(Right now I use two tokens: a real hardware one for online banking — rather bulky, pin-protected, secured by a keychain — and Google Authenticator in my mobile — even bulkier and kept on my body on all times. Both require additional passwords to use.)

Vles • January 23, 2013 9:34 AM

How about a quick tap on your computer with the ring on your finger?

How about we all get barcoded on the forehead?

…Or attach to us some metal object interfacing to computers to read our unique DNA…

B. Johnson • January 23, 2013 10:09 AM

@Kai: That’s one of the big reasons I hate the fact the Facebook doesn’t push the fact that it does offer two-factor authentication. And they could make the process smoother (at least on Android). Right now you have to start the app, wait your home page to load (so you can hit menu), hit menu, scroll to code generator then wait for it to come up. I prefer Blizzard and Google’s (the other two 2-factors I use) where it’s one button to see the code.

Ben • January 23, 2013 12:12 PM

@Vles: “How about we all get barcoded on the forehead?

…Or attach to us some metal object interfacing to computers to read our unique DNA…”

Well, you can change a ring with an RSA code on it, it doesn’t uniquely identify you. You could have a half dozen of the things or have different passwords stored under a common system that it unlocks or….

It’s not like someone’s asking you to take on the mark of the beast or anything. You want to disassociate yourself from an account, smash it with a hammer and chuck it in the bin.

Salach • January 23, 2013 1:14 PM

@Natanael L:

See http://www.plug-up.com

You need just one fold, not three…

A very nice product

For the DIY guys – there is a small smartcard reader from Identive called SCT3511 that accepts a SIM-sized card and is fairly small. Not as elegant as the Plug-up device but still gives you the security of a smartcard.

Natanael L • January 23, 2013 1:57 PM

@Salach: ID-1 standard cards are 0.76mm, USB the bottom part of USB contacts are 2.3mm. 0.76*3 = 2.28mm, so they aren’t following one of these standards or that fold itself adds the extra depth.

Roman • January 23, 2013 2:14 PM

All this effort would be much better spent figuring out how to replace passwords with something that has the same usability properties, while being more secure.

There have been cases when I was able to “resurrect” my decade-old web accounts. The email I used during registration was no longer active. My phone had changed multiple times. But I was able to remember the passwords and login. This would be almost certainly impossible with a hardware token, since it would get lost or broken during inactivity period. People tend to completely ignore things like then when promoting multi-factor authentication.

Natanael L • January 23, 2013 2:29 PM

@Roman: First of all, you’d have multiple backup units. They should be cheap.
There should be some easy syncing method for them to make sure they all keep the same data. This could potentially be done by having them share the same “master keypair” and have the rest continously backed up in encrypted form on a site like Dropbox, or at a dedicated site. Only this hardware device can decrypt this file with all your authentication data as the master keypair have any other copies.
Another option is using Bluetooth 4.0 to perform wireless syncing, but that require that you keep them powered somehow (though sunlight and solar cells could be enough if kept where there is light), and make sure they are in physical proximity.
Then you can have one of them in a bank vault. Or two.

With the device concept I explained previously, you get to decide between a few methods. Got a phone with NFC? Take that card up, turn it on and enter your PIN/pass, hold it to the phone (optionally, verify on the card). You are now logged in.

Computer with accessible USB port? Same as above, but you plug it in instead.

No usable ports on the device you want to use to log in on? Use OTP mode, and instead you do the above but read the code on it’s display and enter it on the site you are logging in on. To keep this secure, you need either a federated auth provider like OpenID, or a graphical list of your sites on the device that you select between (because OTP is based on a shared secret). To keep it unlinkable between your different accounts, you need the list method or a (trustable) auth provider that gives different ID:s to different sites.

RH • January 23, 2013 3:50 PM

“They’ve had to modify Google’s web browser to work with these cards, but there’s no software download and once the browser support is there, they’re easy to use.”

Anyone else think its funny to say “there’s no software to download, you just need a modified web browser?”

aaaah • January 24, 2013 12:24 AM

@RH:
Google’s browser is Chrome, which auto-updates itself. So users won’t have to do anything to receive this functionality when Google decides to roll it out. But you’re right, its kind of funny 😛

Easy USB solution • January 24, 2013 2:21 AM

http://www.schneier.com/passsafe.html

place on USB thumb drive. works on any PC (Linux in beta), device-independent, can back up single encrypted db multiple times on various media, generates random pws of desired length and content (@#$^% etc.), stores challenge Q & A + other info as needed. if lost, useless to thief without your single strong master pw; could copy selected entries for spouse/whoever’s version, etc., etc., etc. …

And Google stays out of it.

Clive Robinson • January 24, 2013 3:44 AM

@ Easy USB solution,

With regards,

http://www.schneier.com/passsafe.html

Whilst it would keep Google out of it, it’s code runs on the PC not the dongle.

Sadly this is nolonger a good idea.

In a perhaps ironic twist Bruce’s comment about attacks improving with time allso applies to Bruce’s PassSafe. And whilst I am not aware of any specific attacks against it, it is nether the less now vulnerable to a number of proven attacks that are used to get encryption keys from memory or readable registers on the CPU or diirectly connected peripherals.

This is problematic not just for all software password safes but also for all USB connected devices that are not correctly designed.

This means that it is not just the password for the individual site being used that is vulnerable but all the passwords and other information stored in the software/hardware that are vulnerable at the same time.

Unfortunatly the only current solution is to have an external device that the only communications channel to the PC is compleatly transparent and strongly mediated by the password holder.

That is the external device communicates directly with the user and the user then communicates directly with the PC.

Which in effect makes it a glorified version of a solution Bruce once suggested, which is to put the password on a piece of paper and store it with all the other valuable pieces of paper you carry around with you all the time –ie money,– in your wallet.

If I was asked to design a piece of technology to store passwords these days I would first insist that all passwords be One Ttime Passwords that changed with time –ie like RSA etc tokens– but importantly also got authenticated in both directions by the use of a shared secret verification protocol.

That is it would appear to the user as follows,

1, The user types their secret pass code into the password device.
2, The User gets the site login page on the PC screen.
3, The User types in their site specific “public identifier” (username) into the PC and sends it.
4, The site sends back a chalenge to the user.
5, The user types the chalenge into their device.
6, The device displays a response code on it’s LCD.
7, The user types the response code into the PC and sends it back to the site.

Whilst the chalenge and response look like random strings of digits, they are actually a time based code that is encrypted by a shared secret between the site and the users device. Thus the device will only produce a valid response code if the initial challenge is valid.

Whilst this gives confidence that it’s the genuine user at one end of the comms channel and the genuine site at the other end it does not rule out malware or the PC or other man in the middle attacks.

Which is why the device would also have to be able to two way authenticate any transaction and most importantly authenticate the actual transaction details.

Sadly this could/would involve a lot of double typing by the user in that the transaction details would need to be entered into both the device and the PC.

I can think of ways to reduce the typing but it would open other –more difficult to exploit– attack vectors, and also make the device less flexible in use.

As has been noted many times “there is no such think as a free lunch” and when security is involved you should also veriify you are not “supping with the devil” in disguise, and that’s a hard problem no matter how long your spoon is.

Natanael L • January 24, 2013 8:04 AM

@Clive Robinson: Your method could actually mean a user won’t have to scroll to the site he/she is logging in on with some interface on his device – the site identifies itself in the that challenge code, and the device can then use a specific shared secret for that site for the challenge-response mechanism.

Clive Robinson • January 24, 2013 9:26 AM

@ Natanael L,

Your method could actually mean a user won’t have to scroll to the site he she is logging in on with some interface on his device – the site identifies itself in the that challenge code…

A nice idea though it is, there are a couple of problems.

The first is the amount of typing required by the size of the chalenge needed for that to work reliably.

Look at it this way the average user probably has twenty or less passwords they need to have be secure. The number of Internet sites they might use number in the tens of millions (or more). Lets assume that it won’t be that long before there are a billion sites or 2^30. In order to reduce the chance of collison to a sensible value you would need 2^60 bits of identifier so the chalenge would be considerably greater than 18 digits long. The chance of error would be way to great.

The second issue is that of what happens when the device checks the challenge against all it’s internal sites list. What do you do when you get an erroneous match?

Realistical both the chalenge and the response should be less than a standard telephone number in size (ie 9digits max) or the user will not want to use the device.

Which leaves the question of if nine digits or 2^30 bits has sufficient entropy to remain secure especialy when some part of it is going to be used as a time re-sync for the dongle to work with.

Oh the reason I say “digits” as opposed to “chars” is to do with the physical size of the device, it realy needs to be able to fit in a credit card size. And if you look at any credit card size calculators you will see that you get four rows of five keys at best with a just about readable LCD.

Which brings up another issue, which is how on earth does the user program it…

The simple answer would be to use Near Field Communications (NFC) and a nice bit of software on the users PC… Except for the fact that if the device gets popular then attackers will write attack code to subvert thee “nice bit of software”.

Such considerations are all part and parcel of the design of “practical” security systems, because it’s a very hard problem to solve (probably harder than designing a new encryption or hash standard).

To see why let me put it another way,

“It’s easy to design a secure system that nobody will use, we know this because nearly all systems to date have been either insecure or unused.”

And I’m sure that several other readers on this blog could come up with their own pet examples or horror stories to illuminate this problem.

Google have bitten off a realy hard problem to swallow and so far I don’t think they have realised that, and thus the result will almost certainly be insecure in the long run.

Don’t get me wrong I hope they do it, but history so far indicates it’s a “Holy Grail” problem.

Ben • January 24, 2013 2:05 PM

You’re talking about this as if it’s going to function the exact same way as passwords; on a per-website basis; and if you were designing a secure system I don’t think you’d do it on a site by site basis to begin with. You’d have a public key that you gave when you registered at the site, and whenever someone typed in your user name to that site and clicked ‘login’ they’d get login details, freshly generated for that session and associated with the requesting address, sent to them encrypted with your public key.

You’d stick the encoding/decoding bit on a USB key, that would only encode or decode and pass the resulting strings for the session back to the computer, and you’d focus your remaining efforts on cutting down on and exhaustively securing that interface, because it’d the point of least vulnerability.

It would be easier for people to use, so they’d do it. It would be more secure for people to use, so that there’d be a motivation for websites to use it.

The worst that might happen is that a particular session might get hijacked, but that would be very hard to do in any meaningful way.

Easy USB solution • January 25, 2013 1:57 AM

@ Clive Robinson

“..and whilst I am not aware of any specific attacks against it, it is nether the less now vulnerable to a number of proven attacks that are used to get encryption keys from memory or readable registers on the CPU or diirectly connected peripherals.”

i don’t know a lot about such things, but it seems to me that if an attacker can get anything at all from my memory or CPU registers, then my machine is badly compromised already, and nothing can be trusted. is this not so?

i have to assume that it isn’t compromised, or it’s useless. so maybe Bruce’s design is still good.

@ Bruce:

do you care to comment Sir?

0day • January 25, 2013 4:50 AM

@Easy USB solution “if an attacker can get anything at all from my memory or CPU registers, […] nothing can be trusted.”

You have to assume that an attacker will be able to read your memory. There are a ton of 0day that he can use, and you money is a sufficiently good incentive for that.

Mark Currie • January 25, 2013 5:14 AM

@Easy USB solution

It is actually possible to provide a secure login in the face of a compromised user platform. It can be done using a security gadget which is a “Trusted Terminal” and without any changes on the server side. With this type of gadget it is even possible to do Internet banking on a compromised platform. We have discussed this before on this blog:
http://www.schneier.com/blog/archives/2011/08/…
http://www.schneier.com/blog/archives/2011/06/…

As Clive says – “nearly all systems to date have been either insecure or unused” (good one Clive).

Natanael L • January 25, 2013 12:05 PM

Clive: Using the calculations for birthday collisions; If each person registers on 1000 sites for their lifetime on average, 5,8 digits/20 bits is all it takes to make sure only 55% of all users see one collision for a given code. So about every second usage they’d see two options on the device screen. If you accept 3-4 collisions on average, you can reduce that number length.

That leaves 6,2 digits left, 20 bits, that provide you a security that lies between that of a regular 6 digit OTP and a 7 digit OTP.

Also, numbers can be grouped to help the user. Example: 4568 4351 8612

Clive Robinson • January 25, 2013 4:13 PM

@ Natanael L,

If each person registers on 1000 sites for their lifetime…

Agh got what you are thinking.

Sorry I was assuming a unique identifier for each and every site on the Internet, but you are assuming each user within a site has a unique identifier so only 10bits or less not 60bits or more is needed.

Yes and after 10secs of thought it would be a better way to go as no centralized authority would be needed to asign identifiers.

@ Vles,

.. if we solve it here on this blog, will they cut us in?

[Strange noise of sarchastic laugh of stage left]

Ii think there may be more than one or two reasons Google get called “The Choclate Factory” atleast one of which might have something to do with Willy Wonker.

My past history tells me we won’t get any credit, and probably accused of trying to steal credit…

For instance, as far as I’m aware I was the first person to publicaly propose using an SMS side channel for authentication tokens for online banking etc after having done research on how to work out some of the problems (SMS is a secondary service and “timely delivery” is not guarenteed, the trick to making it quite reliable is to first ring the phone so the network will find the phone and thus deliver an SMS immediatly, a second trick is to simply send out an SMS to be used next time whilst the user is still logged in).

As we all know many financial institutions now use this method, but I never received a thanks etc from any one.

There is however a slight ammusing side to it, I’d worked out one way of how to break the SMS side channel before most of them started using it…

However I’ve also been given credit where I’d rather I had not, so it’s swings and roundabouts.

However I have two rules I would like people to follow when it comes to re-using my ideas (which I don’t mind),

1, Please mention me as a contributor.
2, If you ever meet me buy me a drink, failing that if you ever meet Bruce buy him a drink and he can buy me one in turn (if we ever meet).

@ Ben,

You’d have a public key that you gave when you registered at the site, and whenever someone typed in your user name to that site and clicked ‘login’ they’d get login details freshly generated for that session and associated with the requesting address, sent to them encrypted with your public key

Ian G over at Finacial Cryptography came up with this idea a few years ago, but for a different reason (anonymous but trusted blog posting).

There are some minor problems with it in the fact that current web browsers tend not to support multiple PK certs, which I’ve identified way back as being a significant problem because it does not alow “Roll Based Activities”.

I had considered using PK Certs, however it was the issue to do with a user having to type things in that made me forgo it’s several benifits.

The reason I did this is I’ve some experiance in subverting communications channels, and I know just how difficult it is to design a channel so it cannot be subverted. But simply the closer you get to preventing subversion the less usable the channel becomes in the more general sense. Now whilst this might be considered a security benifit, it’s most definatly not a benifit as far as the marketing department et al are concerned. Thus realisticaly I could not see a hardware dongle being produced in practice that could not be got at by malware on the PC to which it would be attached (I indirectly mentiond this above with my comment about ‘… Except for the fact that if the device gets popular then attackers will write attack code to subvert thee “nice bit of software” Such considerations are all part and parce…’)

As I said above it’s a hard problem to solve and I’ve been thinking about it on and off since the early 1990’s. I also know that @Nick P and @Mark Currie have had quite serious thoughts about it, however they are less squeamish about “direct connection” to a PC than I am and were looking into if a USB interface could be made sufficiently secure. My vote on that was to use a USB to serial converter chip and heavily mediate the serial interface to the device with a hypervisor, but that means using a second processor etc which would be seen as a needless expense in a cost sensitive market.

There is also another issue which is “connector wear” some connectors used on commodity PC’s are only good for fifty or so operations cycles and then they (may) start to become unreliable which is why I sugested IR but these days would probably go with Near Field Comms (NFC) for which suitable chips are becoming available at sensible prices at last.

Natanael L • January 26, 2013 11:12 AM

@Clive Robinson: I was thinking that the site first provides the user with a code like that which he enters to the device (so he can have unique shared secrets per-site), and THEN he also enters his username and the response code to the site.

Untrackable in-between sites and secure. Still works like those challenge-response security tokens that many banks use.

David Valentim Dias • January 27, 2013 6:50 PM

Google offering services…
“I provide OpenID but I don’t accept” trollface

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.