[cryptography] oneid single-sign on stuff (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)
adam at cypherspace.org
Tue Oct 1 16:17:00 EDT 2013
I didnt see your comment lower down before (quoting got too long).
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
>>>i like the idea. Any issue/complications with re-provisioning or
>>>multiple devices with same identity?
>>If you lose one device you can replace the device enrole it authenticated
>>by your other devices and securely restore access keys into it. It does
>>support multiple devices, though each device also has a unique key as well
>>as a common identity key so that individual devices can be revoked
>>instantly if they are stolen. It uses some fun crypto like a blind MAC to
>>do split key KDF and AKE type protocols.
>so I wonder:
>- with no server[correction password], what would be the user perception of
>security? Say, you log into your online banking with no password; would
>user feel secure and use the service?
There would be still a password or a pin typically so that perception is
still there somewhat. But the password is used locally only (together with
a server input to prevent offline grinding to decrypt the private key in
event of stolen device). The key derived from the password/pin and server
input is used to decrypt the device private key. The device private key
makes a signature as part of an end2end secure challenge response with the
>and would that prevents them from using such systems?
There is a bootstrap problem - oneid has to gather some relying parties and
persuade them to integrate the system. They have integrated with some
commerce and banking platforms and some partners. You could imagine it
being like other 3rd party integration where a bank might use also their own
info on top (account number etc) though that can be handled by oneid (it
supports encrypted relying party specific account info and form filling).
>- would Facebook/twitter and co. like this sort of security where
>users cannot log-in from anywhere from any device? Surely they prefer
>a bit less security on client side + more ML detection server-side
>and more users connected; right?
In principle as I understand it user account theft, locking themselves out
by forgetting passwords and resets cost big players like
facebook/twitter/paypal etc big bucks like millions annually. Security
cleanup after the inevitable server compromise and hashed password db theft
cant be a lot of fun either plus the negative PR if it comes out publicly.
Real disservice to the users too who often use same or similar passwordws on
multiple sites. So you would think there is a business case to improve
Similar password management is a pain and people leave new sites by clicking
back when faced with yet another "please signup". You see it now in some
sites starting to let you login with unrelated twitter or facebook just to
save their users the pain of managing yet another password from even an
unwanted relationship. (All you want to do is read the new article or
report!) So then there should be an interest for the company to allow users
to authenticate. The uptake of twitter/facebook in that role bears that
out. But it also not very privte - I dont know what facebook are doing but
they're probably prone to blog about your login or enrollment on your
facebook wall, if you're not careful. They certainly know where you logged
in and where you enrolled. (Which oneid takes pains to prevent itself from
learning as all relying party traffic is direct from user to relying party).
>- I guess the sort of service you describe is great for large
>companies; but the complexity might put off smaller ones. Thoughts?
Well from a user point of view its very simple. The site integration is
supposedly rather easy also, though I know less about that.
https://developer.oneid.com/ there are SDKs and APIs.
>- how different is the client cert approach compared to token used on
>mobile devices (e.g. Google stores a unique token on smartphones to
>access google services and hence requires no passwd)? Essentially it
>too removes phishing problems, but seems more flexible.
Google device auth is on the better end of things, but oneid its a
generalization of that concept - because its federated in a way where you
dont have to trust the federation server operator, and yet can use the same
device to login to multiple mutually distrusting services operated by
different relying parties. Also oneid has server split key so you can not
access the device key without pin/password, and 3 wrong guesses locks your
device as enforced by the server. The server also cant access your device
private key, you would need the device and the server db (eg a stolen copy
or subpoena of the server factor for a given user) plus then to grind the
actual password. I'm not sure if google would track the login if used by a
third party - I guess they would want to because they like to track and
record everything for posterity in case they can squeeze some latent ad
revenue out of it. (No evil and all but thats a big database for the NSA to
get its fingers into).
I'd say another problem might be control. I suspect google, facebook,
twitter, linkedin, microsoft passport/live/namedujour think they "own" the
account and want to decide if/when the credentials they manage are allowed
to be used to login to other services. eg you hear now and then of
successful small businesses and individual web20 mash ups being
uncerimonially just cut off or dumped from some of these sites APIs and
logins with no further explanation.
So maybe they dont want to solve the single signon problem because they have
the ambition to control and own user identity, but to do that force you to
use their lame password scheme.
There's a 7in video I noticed by Steve Kirsch that explains oneid better and
mostly in more detail than the white paper really:
>But it [google device auth] does not have fancy crypto so maybe less
>exciting on an intellectual level :-)
Yes the crypto was fun, but the Kirsch guy has a razor focus for usability
and customer focus. So the complexity is actually all tracked back to
specific security advantage or customer feature, and pretty much hidden from
the relying party and user.
More information about the cryptography