So there'll be a centralised list of all the places I have accounts? Sounds like this might benefit...not the user.
A pair of authentication standards published this week have received endorsement from Mozilla, Microsoft and Google: the WebAuthn API, and the FIDO Alliance's Client-to-Authenticator Protocol. The aim of WebAuthn and CTAP is to offer an authentication primitive that doesn't rely on server-stored passwords, since a user's …
tried before. Micro-shaft 'Passport'. Failed then, too.
And don't forget "Log in using Face-bitch". NO tracking THERE, right??? Or 'log in via Google'. Same thing.
A centralized "single point of failure" logon for the ENTIRE intarwebs is likely (like a 'Micro-shaft account' for your windows box) to TRACK YOU EVERYWHERE. Why? Because there has to be a server side credential exchange for EVERY! SITE! you visit that's "aware" of it.
And their revenue model: slurp a few cents for every site that uses the API, but only for BIG sites [which is what Google does for things like 'maps']. If you have a low access rate personal or company site, it'll be free. if you have a million hits a day commercial site, PAY UP!
yeah you can see THAT coming... no, wait, ALREADY HERE (for maps anyway, as pointed out previously):
I'd expect that to be (eventually) extended towards the "common logon" as well, if it's ever adopted.
let's hope it's NOT EVAR adopted. it's bad enough ALREADY when web sites give you a 'forbidden' response when you disable script. Last thing I'd EVAR want is to see the vast majority of web sites buying into this crap and DEMANDING a login.
@bombastic bob, oh MAH GAHD! DA-RAHMAH! *eyeroll*
This is not much different from password managers already, except good implementations of these and other APIs (and methods of 'automatic' authentication) can mitigate risk significantly.
Google does OIDC already, Facebook does too, the scientific and academic communities ON THE PLANET rely on OIDC, SAML (SAML2 Web Profile to be specific), and certificates, so this... this is just a natural progression.
Nothing overly DA-RAHMAH-tic here.
Isn't this what Facebook tried to do with their support for using Facebook ID to log in at random sites all over the web? Of course you have to enable the app platform, which allows for the data grabbing ala Cambridge Analytica. Probably the reason they pushed the logins, in fact, to get more people to enable the platform - and make it harder for them to leave even with all the negative publicity about it recently!
"So there'll be a centralised list of all the places I have accounts?"
Only on your own device or application.
You can think of this standard as a password manager, only instead of being a database of passwords it's a database of secure cryptographic keys. How these keys are secured is then up to the device. It could be some snazzy phone-based biometrics (e.g. fingerprint, facial recognition), a yubikey, or a bog standard pin or password.
The point is those credentials are limited entirely to your device and can be extended to test for user *presence* and not just verifying the password.
You log into a local application using gestures, fingerprints or whatever and the local application talks to a server and says "This really is John Smith here, I'd like to transfer some funds...". And the server says "OK, your ID has already been verified, so your funds are being transferred..."
So does this mean that if someone mimics the behaviour of the local API and protocol used to communicate with the server, they could fraudulently send bogus authentication messages to the server?
Sounds well dodgy to me if authentication isn't done at the server end.
"Sounds well dodgy to me if authentication isn't done at the server end."
Authentication is certainly done at the server end, just with per-agent cryptographic keys rather than a shared password. It's then up to the agent (i.e. your device) to ensure those keys are securely stored. Most phones and enterprise devices already do some form of this, this is a generalisation for the general web.
> So does this mean that if someone mimics the behaviour of the local API and protocol used to communicate with the server, they could fraudulently send bogus authentication messages to the server?
AIUI The server holds a public key for your auth device. The auth device then signs a server-provided nonce with the private key to prove it has control.
That private key might in some way be derived from your gesture or fingerprint, but is more likely to simply be unlocked with it.
So to do what you suggest, the attacker would need to have gained a copy of the private key on your authentication device. If someone lays hands on your private key then it's game over anyway.
I suspect where this will probably fall down in practice though (aside from uptake) is there will inevitably be some crap authenticators hit the market (for example who's fingerprint reader can easily be fooled)
What are you supposed to do, get a fingerprint or iris transplant? The techno utopians who've watched minority report one too many times and who thought these methods up really need to come back down to earth for a second and consider what happens in the real world. Passwords can be changed - biometric data cannot and once its been discovered thats it, you can never securely use it again.
The bigger problem is that as of current state, biometrics are not even _as good_ as your username. Biometrics often cannot tell that I am me (poor lighting, not holding the sensors in the "correct" relative position to the bio being metred etc).
If biometrics cannot reliably identify me (false negative) then it must be allowed that they might sometimes be confused hat someone else is me (false positive). Even if that is not the case, only being able to identify me as me when particular environmental conditions pertain is equally dumb. I am only me when I am well lit me ? Hmmm, maybe that's why some people prefer to get intimate with their partners only with the lights off ?
Are usernames really any better? For sure I can deliberately provide a false username if using a username as... my username... but nobody relies on _just_ a username for authentication. That would be stupid.
Good observation, biometrics are best used to prove who you are - not authenticate as credential. It is only a matter of time before biometrics are rendered utterly useless as a weak authenticator method.
As biometric repositories build up around the globe the possibility of false acceptance rises, I would foresee Asia as the first continent by population that has their biometric profiles copied! Between the Indian Aadhar initiative and the secretive Chinese authorities, they will probably file all but your back village laborer’s profiles before this year is out!
How can you trust “probably” when your profile is dotted about everywhere, analogous to walking around with 'that' post-it note on your forehead!
Did you know that the certificates created (and managed) by OpenSSL are merely sets of public/private keys? And that your certificate signature request is basically nothing more than a public key which gets signed by another party? And most of all: that the signature defines the trust in the eventual certificate?
Why I'm telling you all this? Simple: because this can be a very feasible form of authentication as well. Heck, I'm using this with my (hobby based!) VPN (powered by OpenVPN). Basically I have my own private CA which is trusted by several computers (FreeBSD, Windows and Linux alike), that signs off the allowed certificates for VPN use and those clients merely have to use this certificate.
Or what to think about SSH? I'm not using a mere password for that, I'm using public key authentication. So: my public key resides in ~/.ssh/authorized_keys and my private key is just that: private and used to authenticate myself. The only password I use is one to keep my private key safe.
Why can't we have this instead? You could even automate the certificate creation part and there would be no need for any centralized user tracking center.
My (cynical) take on all this? Revenue. Of course they won't use certificates because too many companies have financial stakes in those. It's much more beneficial to sell us that crap than to confess that it could easily be used in a different (and cheaper) manner. Money makes the world go round,eh?
Cryptography in SSH does not necessarily require Public Key Infrastructure (PKI) for authentication. GSSAPI also works. Password also works. Certificates (*not* public/private key) also work. This is just another plugin...
That the comms channel is encrypted is separate to the authentication mechanism that does it *over* the comms channel. GSSAPI is, bizarrely, doubly encrypted in SSH (SSH's own comms channel, along with the encrypted tokens being passed along).
"Cryptography in SSH does not necessarily require Public Key Infrastructure (PKI) for authentication. GSSAPI also works. Password also works"
GSSAPI is just an API, not a method.
As for password, it doesn't matter what you call it, password, encryption key or Trevor, you still have the same problem of sending someone encrypted data without them giving you an encryption key someone else could intercept and use as a decypt key. This is the problem public-private key was designed to solve and quantum comms aside its currently the only method.
This is also possible for proxy authentication. I think the thing that's different with this is that it will standardize what happens on the browser end. Currently, they all handle it a little differently (well, Firefox variants vs. IE variants and those that use Windows handling like Chrome).
> Why can't we have this instead? You could even automate the certificate creation part and there would be no need for any centralized user tracking center.
That's basically what this is, just wrapped up in some sort of hardware token.
In fact, that's basically what your Yubikey or FIDO key is too
A biometric is not an authentication mechanism, it is merely an identifier.
People who use biometrics as passwords are basically of the opinion that with a sufficiently complicated username, you don't need a password to be secure.
There are plenty of people willing to take full advantage of such ignorance.
The reason hardware-based tokens are usable is that they are only associated with an identity, and that association can be broken if it is necessary, and a new token associated with the identity in its place. This is difficult to do with fingerprints, retinal scans and hand vein patterns (easy to break, not so easy to substitute).
I have no problem with the theory of using private keys to encrypt stuff that you use to authenticate. I have no problem using external devices to store them. I do have a problem with people theorizing that this will solve the problem of credential stealing, as most stealing operations don't use network traffic, instead going for the data on client or server. A properly salted hashed password may be slightly less secure, in the sense of taking a million years instead of a billion years to crack, but we have seen that a lot of systems don't go to the proper extent to properly salt and hash their passwords. Those people probably won't be implementing a more complex and entirely new system, so they will be as much at risk as they were before.
So the question remains: is it easier to get a password or a private key if you have access to the client machine, and is it easier to repair such a breach if you use passwords or private keys. In both cases, I contest that passwords are better. While some systems will store passwords on the system, leaving them a sitting duck for attackers, it is possible and frequently the case that users must type them in. Of course, a keylogger can collect them, but it requires more complexity on the part of a malware writer to determine what is the username, what the password, and where those are effective. It doesn't mean it won't happen, but at least it reduces the likelihood. I don't think the same complexity exists with private keys. Some systems will properly store them on external devices, but there are too many lazy users to make that the only option, leaving the other option (storing them on a disk) the more likely. An attacker can learn their location and just copy them over. So now we turn to after the attack, when the intrusion has been detected. In order to reset a password, one simply goes to the reset password function and authenticates oneself with email, and the password has been changed. The old one is revoked and the attacker has lost access. The same can be done with private keys, of course, but the system will result in a lot of inconvenience. For example, I have different SSH keys for each device I use for SSH. I would either have to revoke all of them, or have a system for finding which keys have been captured so I can just revoke those. Furthermore, any system for storing keys that keeps using the old ones will stop working until I can update it. For those of us who are technically aware, this process is quite straightforward, but my family members are going to deal with this crisis by calling me and asking for help. For those who don't have a helpful acquaintance, they will get frustrated. The results of this will not be pleasant.
In a world where Windows and Linux make the USER type passwords incessantly or at least click to give approval, but allow installation of their own packages, there is always a case for better security on the net, but there will never be a case where it can be provided.
USB ID dongles have been around for a long time, ultimately signals are sent through a bunch of wires that can be emulated. "You'll never have software reproduce MPEG they said..........." they did almost before they had finished the sentence. and they will reproduce dongle emulation, they have in the Music industry e.g DAWs with Cubasis and the like. The dongles get better but so does the emulation.
Do you want your System exposed to the internet as it has to see your USB ports, or one of them, Your Bluetooth is probably internally connected to USB, as is your mouse and keyboard, or touch screen. and much more. Are you one of the people longing to share the unique ID of IVP6 addresses of every device you own across the Internet to be followed everywhere with ?
Then there is the browser it will just 'bot' along in the same way as all the other similarly branded browsers. Auto logging in for you, your browser is consistent, it gives you a logon page and you click log-in, if it remembers you. If you have other things to do it sits there waiting until you can focus your attention on it.
It is all just to make you feel comfortable about the internet and commit to more ID across it.
If you want "security" stay off the Internet, and computers. These are tools of 'convenience', and with ever more convenience your security is lost. Security is does not come in half measures, it's something of the 'if you've have it then you have to have it all, if you don't have it all then you don't have it.
Sorry but I find it hard to trust all the "keys of the kingdom" to a specification (U2F) containing phrases such as "assuming the browser is working as it should", especially in the same sentence as "this is a critical privacy property". Furthermore, as long as U2F in practice seems to mainly just mean "Yubikey", which specifically chooses to base the security of every single account you entrust to it to ONE single, common, fixed (to the key) secret, I won't be using any of it thankyouverymuch. Especially seeing as how they still want me to remember a per-site password, completely eradicating the need of which being the absolute minimum I would expect in exchange for agreeing to keep all my eggs in a single basket that isn't my brain.
This post has been deleted by its author
We must look at what are NOT MENTIONED.
Firstly, biometrics that is used with a fallback password against false rejection provides the level of security lower than the password.
Secondly, physical tokens and devices that store biometrics data, cryptographic keys or passwords are as subject to loss, stealth and abuse as a memo with a password on it.
Refutations against this observation would be welcomed.
Biting the hand that feeds IT © 1998–2022