Among the pieces of evidence that Google suggests the Trust API could
use are some obvious biometric indicators, such as your face shape and
voice pattern, as well as some less obvious ones: how you move, how
you type and how you swipe on the screen. With the service continually
running in the background of the phone, it can keep track of whether
those indicators match how it knows you use your phone.
I’ll stay with good old passwords and possession-based MFA, thanks.
Did anyone tell Google that biometrics remove consent?
You just need to train it to stay locked with your duress face.
Same. Ever since I heard of this I have had a hard time understanding why anyone thinks this is a good idea.
I find it difficult to change my biometrics, as opposed to my passwords, if the need arises.
You wanna know how I got these scars?
2017 Everyone changes from passwords to biometrics.
2018 Chinese hackers access Apple/Google/Microsoft/Facebook servers and get access to everyone’s biometrics.
2019 Everyone changes from biometrics to passwords.
2020 Cars made in 2017 are still frequently stolen, some have been converted back to key/remote/card access.
In my opinion biometrics are useful username replacements; certainly not password replacements.
Security aside, don’t you think widespread use of biometrics is sort of dangerous when everybody’s data is controlled by a few companies and governments?
My Nexus 5 just broke, I’m looking at a Nexus 5X but first I want to check that I can either disable or at least put masking tape etc. over the fingerprint thing on the back. I don’t mind my phone knowing my biometrics, but I don’t really want that data uploaded to any corporation, even if you use Cyanogenmod (Or any other OS) you can’t tell what the phone firmware itself is doing with that data. Same goes for laptops/desktops, fingerprint/palm readers at your work or at the airport, fingerprint readers as a replacement for car keys, etc.
On a side note, you gotta admit that at least Google is not as dumb as Apple to suggest that fingerprints are considered secure. The CCC showed that Touch ID can be broken.
Touch ID is secure enough against the maximum threat model I – and many others – are worried about.
Also, while Apple doesn’t define a threat model, careful reading of those claims lets you construct one. Apple takes care to claim that Touch ID resists other people’s fingers inadvertently unlocking the phone. They never claim to resist directed attack.
The cynical reading is to say they rules lawyered their statement to sell Touch ID in the best possible light. I’d agree.
Are passwords ‘broken’ in general? I don’t see the need to fix them.
Passwords are pretty insecure. Most people reuse them. Compromising their password in one place (eg. Neopets) will allow you to assume their identity on most other services (Google, Facebook, Amazon, maybe a bank).
Is it passwords that are insecure or the person behind the password? If you use a password manager that lets you generate strong and unique passwords then I don’t see an issue. Then if a site gets compromised you just need to regenerate a new password for that site and not worry about the others you may have used the old password on.
At the end of the day, it comes down to making a conscious effort to be smart about how you maintain your online identities.
From a policy perspective, there’s not much difference between “this cannot be used securely” and “this is not used securely”. The net result in either case is poor security, and bemoaning the fact that people don’t pick secure passwords doesn’t solve the problem.
Obviously from a personal perspective, there’s a lot you can do to maximize the security of your passwords (starting with generating distinct long, random passwords for everything and keeping them in a password manager). But your good password practices don’t really matter to Google, or anybody else using those passwords to authenticate you.
Many security issues will be closely linked in some way to people. If your security mechanisms can’t account for the soft exploits, it’s an insecure system.
The problem is that most people don’t do this, and there’s only so much a site can do to encourage its users to do this. In the end, it can’t tell if your password is used elsewhere, or from a password manager, or anything else. What they can do is look for some method of authentication that avoids or augments the password, to (hopefully) provide a greater degree of security by default.
Passwords are absolutely broken.
LinkedIn was hacked 4 years ago, 164 million accounts compromised, and we just find this out in the past month?
Https? There’s no way to ensure that it’s even set up properly. The DROWN attack and heartbleed are both great examples. https://thehackernews.com/2016/03/drown-attack-openssl-vulnerability.html
Depending on any multi-use token for authentication should be considered poor security.
Https? There’s no way to ensure that it’s even set up properly.
I’m not sure what this has to do with passwords.
They’re typically transmitted over HTTPS; doubly a problem if they’re reused.
If this is a problem for passwords, isn’t it also a problem for biometric data sent to a backend?
Edit: in fact, all biometric data is “reused”, so wouldn’t that be even worse because once someone captures whatever data your fingerprint is turned into they can use that with any system that uses the same type of data?
[Comment removed by author]
Korelogics analysis of the Linkedin hash dump shows some interesting issues with the use and generation of passwords.
I’m not sure what the solution is - but for me passwords are part of the problem.
Here’s the thing: You’d have a similar problem with storing biometric data. Biometrics are strictly equivalent to a reasonably strong password, from the server’s perspective.
They’re quite different from the user’s perspective, but I’d argue that they’re a step backwards because they’re immutable.
Wasn’t the hack acknowledged way back in 2012? The new thing you’re hearing about is that the hacked passwords are finally being used.
What you’re saying is that passwords are broken because LinkedIn is a bad company and some people implement HTTPS wrong. That makes no sense.
What would you do instead, in the context of a web application needed to authenticate a user?
The headline claims more than the story actually does, with regard to the intent.
Crucial to the API is opening up the service’s estimates of security. Rather than giving a binary answer, as a password does, the API can hand over a score to indicate how confident it is that you really are you. If the institution needs more confidence, it can feed back and ask for additional mechanisms: more biometric data, for instance, or an old-style password.