Google will begin testing password-free login to Android apps | Hacker News Reader

Google will begin testing password-free login to Android apps

theguardian.com

97 pointsjonbaer81 comments

> 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.

This is different from a password in my eyes. A password only proves that I know a secret. It can prove that I am the same person who signed up for a service or at least that I was trusted with the password by the person who signed up.

This Trust API on the other hand proves that I am a specific individual.

A password is like a pseudonym. The Trust API requires me to reveal my full identity.

I think this is big step back in privacy.

And in security.

You can change your password as often and as frequently as you like, and you don't wear it for everyone visible over your shoulders.

Not to mention, a password can stay the same, but if you break your arm or lose your nose, your biometrics or swipe behavior may no longer be the same.

And a password can change. If someone works out how to mimic my biometrics, what do I do?

Break your arm or lose your nose, obviously.

Break the other person's arm or nose?

> I think this is big step back in privacy.

s/privacy/surveillance

Thinking the same thing regarding privacy.

I'm all for getting rid of passwords, but the idea of Google (and other service providers) keeping that much information on me would definitely push me to getting rid of smartphone. Yes, I know that Google, Facebook, etc. already know a lot about me. But I still have some control over it. And a lot of it are things that I can and do change over time (what they knew about me 5 years ago doesn't necessarily reflect who I am now).

Not to mention that if this catches on, ever more parties (that you authenticate with) will be collecting these biometrics, which means there would be an ever greater chance of that data getting used to impersonate you.

To avoid this they would have to keep it on the device, in a secure enclave, in "hashed" form rather than the raw biometric, and only transmit the fact of authentication to Google, much as how Apple deals with Touch ID on the iPhone.

We all know Eric Schmidt's view on privacy:

"If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place. If you really need that kind of privacy, the reality is that search engines -- including Google -- do retain this information for some time and it's important, for example, that we are all subject in the United States to the Patriot Act and it is possible that all that information could be made available to the authorities."

"We know where you are. We know where you’ve been. We can more or less know what you’re thinking about.”

“Your digital identity will live forever… because there’s no delete button.”

> Not to mention that if this catches on, ever more parties (that you authenticate with) will be collecting these biometrics

... and then doing data science over them. It's like Phrenology all over again!

I'm all for not getting rid of passwords, because everything proposed to replace them so far has sounded a lot worse.

Users like me neither store sensitive data nor conduct sensitive communications through email. I do not need infallible security; reasonably reliable service is enough.

You don't consider access to almost all of your accounts to be "sensitive"? Remember that the vast majority of services let you reset your password by sending a link to your email. So anyone with access to your inbox effectively also has access to any other account associated with that email address. I think it's a rare person who doesn't have a single digital account without anything sensitive in it.

>I think it's a rare person who doesn't have a single digital account without anything sensitive in it.

I'd wager they don't exist for anyone who uses the internet or social media on a daily basis. Most people don't realize how sensitive the information they post online actually is.

Many people don't consider the names of their family members to be "sensitive information" (hell, they happily tag them on Facebook!) There's a good portion of people who don't consider the town or state they live in and where they work to be sensitive information. There's a large portion of people who post unpopular opinions and don't treat their opinions as plausibly sensitive information.

None of this is sensitive information until they have an internet hate mob knocking at their employer's door trying to make them lose their job - or when their family members are harassed or get told things that said individual would have preferred to keep secret from them. Because in their heads they've convinced themselves they have never done or said anything wrong to anyone and what they said in the past will never come to bite them in the ass in the future because popular opinions will never change and they're always on the "right"/"winning" side.

Yes, the equivalent to a password in the physical world is a key. Or something like the tagged jewellery they were suggesting before:

https://www.technologyreview.com/s/512051/google-wants-to-re...

I agree this seems like massive overkill. Biometric data is what you'd associate with a passport, or id card, or perhaps require for access to a bank account. That kind of data being used to log-in to a website is a big step.

Fully agree.

And how long until a TLA says ok Google/Apple for these phones give us all the biometric data on anyone who's used it.

For example a phone found at a terrorist safe house the FBI woud love to see who had been using that phone

> 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 wonder how this would deal with changes in your behaviour, lets say, due to illness or disability.

If I'm ill and high on painkillers, will the system lock me out? If I lose my right arm in an accident, (or even if my right arm is pinned under something and I desperately need to use the phone), will I be blocked from using the phone?

I think this stuff sounds like a good idea in a vacuum, a vacuum in which you can presume you'll always be in the same state of mind and body as what Google consider 'normal'.

> if my right arm is pinned under something and I desperately need to use the phone

I have pattern locking today, and "emergency call" button on the lock screen is already a thing.

I would imagine this would be option #7 or so for the lock screen. Depending on your phone's hardware, etc.

I used to treat my phone like my wallet, aka no lock at all beyond anti-butt dialing swipe, but some obscure corner of VPN setup required more extreme measures.

I assume that any lock technology on my phone is on the level of a kids diary book lock, and act accordingly. Anyone with physical access to my phone owns all of it, so I'm pretty happy with "swipe to unlock" and not happy about big brother authoritarianism WRT vpn configs and lock screen choices. I don't find a bunch of security theater about "wiggle analysis" or facial recognition to be interesting or useful and mostly want to know about it so as to avoid it.

Anyone with physical access and lots of money to pay for a bespoke exploit (assuming you're using a phone where that's possible), sure they have can have access if they're willing to put in the time and considerable money it would take.

If you're ok with the risk posture of not locking your phone that's your decision, but you're quite wrong about the level of access granted merely by possession of a modern smartphone.

What would be the amount of users who use a proper password on the lock screen, instead of the pattern or a PIN? I bet the actual pattern space is very little for these and these are very guessable. How hard would it be to brute force these or even analyse the human fat on the screen to figure sth out?

I unlock and lock the phone very often, unlike a computer where I unlock once and lock when my session is done. Thus I opt for sth quick and convenient instead of a proper password. I'd like to have a little chip like a yubikey that I'd use with an ordinary pattern or pin, guess that'd be the best approach that's both convenient and secure.

You're describing the exact use pattern touch ID was designed for.

That seems very complicated compared to looking at security camera footage from the hundreds of cameras I walk past. Type in the code you see on the video and there you are.

Likewise no one in .com or .gov technically needs my phone other than to look at what I might have saved locally on it; they own everyone from the mfgr thru the telco thru every app writer and SaaS provider either by just buying/sharing data or NSLs.

Do you also not lock your front door because someone could possibly take a picture of your key and 3d-print one, then follow you to see where you live and rob you?

Coming up with theoretical nightmare scenarios is fun and all, but you should try to bring some reality to your security decisions.

1 - patterns and pins are not as insecure as you apparently believe (consider that length isn't mandated and watch the search space explode). Enable the "10 tries and it's wiped" setting and get on with your life 2 - I wasn't talking about Joe public, I'm talking about the type of person who posts in smartphone security articles on HN. They'll pick a good enough PIN/Pattern 3 - we're not trying to secure against an advanced adversary, by far the most likely bad actor is the thief who pulled it out of your bag at Starbucks. A PIN/Pattern is fort Knox to them.

Security is all about risk mitigation, you have to consider against whom you want the system to be secured.

3. You can't know.

2. No they won't. I don't. If I'll type a password once, twice a day, that's okay. But I draw that pattern or pin tens of times a day.

1. See VLM's post on this thread.

0. You can't ever know who you'll deal with. All you'll know will be "somebody has it".

You're totally missing my point. It's not that I can't know, it's that I don't care. You can't secure a phone against nation-state actors, so don't try. Do enough security so that the random person who steals your phone to sell it doesn't also steal your personal photos and bank info, order stuff from Amazon, use your phone to call their Uber, etc. They're more likely to be who has your phone anyway.

Re-read the bottom of my other post, security is about balancing cost of mitigation against predicted impact of threat. State actors are very unlikely and very expensive to mitigate. Petty theft is more likely and cheaper.

Biometric authentication is a decrease in security for users, not an increase.

Biometric authentication can, as an additional factor, with proper management (which is non-trivial) be a benefit to security fire institutions that need to safeguard against sharing of credentials, but replacing other authors mechanisms with biometrics rather than augmenting them makes biometrics a net negative.

For some consumer uses they are an increase in convenience and may be a better security vs convenience balance, but that's undermines if they are misrepresented as increased security, because then users will be choosing them on faulty premises.

Correct.

They should spend more time to develop better management of passwords.

I would like to have a poem generator that generates unique and easy to remember poems, that can be used as master passwords.

...Which, because of all the rules associated with a poem, would have shockingly low entropy and therefore not be good passwords in addition to being a pain to type in.

You know that there are many different types of poems, some of them don't even rhyme.

Yes they are more painful to type. But long alpha numeric passwords with symbols are painful to type too.

I've been thinking about a project along these lines, on and off for a long time. The basic premise is that we need passphrases - that is strong passwords that are usable to derive symmetric keys from (and can be used to, among other things protect the private half of asymmetric keys, and/or unlock databases that manage user/site/password tuples). And they need to be random, and easy to remember.

Ideally we'd want such pass-phrases to have 128 bits of entropy, although I suspect just getting to 64 bits would be a big improvement on most general password/pass-phrase schemes (Does anyone know of research into how stretching a 64 bit key to 128 bits affect real-world crypto-systems? Assuming a "slow"/"good" stretching/key derivation scheme, and the use of a salt, I suspect it might be "good enough").

Now, some napkin math: The English alphabet consists of 5 vowels and 21 non-vowels; we can generally start words with a combination of the two, and some words (like "two") start with a sequence of two non-vowels. 5 * 21 = 105, with another 23 combinations we can reach 128. That's 7 bits for a single word out of a list of 128, identified by it's first two letters. To reach a minimum of 64 bits, we need 10 such words, or perhaps two sentences of 5 words each (Note that there is little help in captilaization here, that single bit doesn't really move the needle on the number of words we end up needing -- considering the difficulty of remember which of a set of random letters are capitalized).

Creating word lists of 128 words is quite easy - we could have some lists of substantives, verbs, adverbs etc - it might even be possible to find words that rhyme. So we could probably construct pass-phrases like: "[The] small red car drives quickly", "huge scary horse hides sadly" -- which we can input/verify/use in their "short form" encoding 70 bits: "smrecadrquhuschohisa". To get through password "security" tests, we might say that the first letter is capitalized, and a period added on the end (possibly we should throw a number in there as well, but hopefully three letter classes are enough for most "checks"): "Smrecadrquhuschohisa." or "1Smrecadrquhuschohisa."

Note that the point here is that the words can be generated just as we generate symmetric cipher keys - from a random 70 bit number -- and are just as secure (or insecure) as such keys are. The rule-based capitalization and punctuation doesn't add any entropy -- it's just there in case we need to get accepted by legacy systems.

Also note that, even this simple scheme, requires a lot of typing for just 70 bits. At 7 bits per word, we'd need 19 words to go beyond 128 bits - which probably means it would be just as well to go for four five-word sentences.

Now, the point of all this, is that if you want a poem that lets you remember 128 bits of random data, you have some work cut out for you, if you want this system to be based around simple generating rules, that are obviously without any bias (no more bias than what you find in generating symmetric (session) keys).

I've been playing with this idea for a while, but so far it seems ~64 bits is a likely "wall" for easy to implement correctly, in a way that's easy to use.

Other options is to use a graphical input - with emoji or images in a grid, possibly with the added factor of colour (eg: red/white, blue/white, black/white etc) - but 128 bits of information turns out to be a lot to encode!

To start with, never abbreviate passwords. You're making it more ambiguous, creating more possible sentences that could match the same output.

The better solution when length is capped is hashing and something like base64 encoding.

Regarding KDF:s, they only add as much difficulty as you put work in. If you put in 256x the work, you get log2(256) = effectively 8 extra "bits" of entropy worth of bruteforce resistance. You want 80-100 bits in the long term.

[ed: apologies if the first section come off a bit hostile, that wasn't/isn't my intention - also see my sibling comment. I appreciate all feedback!]

A) I don't think you read the encoding bit correctly: the secret is the first two letters, the extension to words is just a mnemonic device - a crutch for the human brain. Typing a (full) paragraph blindly will be too error prone. While one could argue that it would increase the entropy, the basic idea is to have a trivially obvious lower bound on the entropy a password encodes.

B) let's say we change the method to just generating a random 0 or 1. Would you feel comfortable using this password as a Base to derive a 128 bit aes key, and telling the world about your password scheme?

[ed: I'm not sure if a good work-factor+a decent salt would be a reasonable basis for deriving 128bit keys. You'd want it to be hard to "walk the keyspace" that your 64 bits + salt extend to. In the trivial case of passwords "0" and "1", you'd need a long salt - but you'd also have to do all that work yourself every time you need your key. As I understand it, 64bit is still "quite big" -- I'm just not sure if it's big "enough" in this case. I'm thinking no - but I'm not certain.]

> You're making it more ambiguous, creating more possible sentences that could match the same output.

Yes, but can you quantify how much entropy is in those letters and spaces that are chopped off? In an obvious way? I agree that there is (probably) no harm in and of itself of including them in the password, but as mentioned in the sibling comment, the main point is to have it obvious what level of entropy is encoded. As the word tables and system is designed to be public, the don't encode more secret information, except in the case where the attacker isn't attacking you/this system specifically. But an attacker could, so I'd rather avoid the false sense of security that the handful of extra bits full English words would add. And as mentioned, it adds to the difficulty of typing in the password correctly, from memory.

> The better solution when length is capped (...)

While systems might cap length when storing/validating passwords, the capping here is for the human part of the system. How and what to remember, how and what to type. It's a user interface/interaction improvement over other password schemes, not strictly a technical scheme.

Basically the problem it tries to solve, is how can we easily remember n numbers of random data, and communicate it to our various systems, both new, and legacy.

Note the alternative, for a simply "fully random" ascii-based password, we have:

26 letters (that can be caps), 10 digits, roughly 32 symbols[1], and we might want to add space, for roughly 95 characters that might be reasonable to use for a password. I personally think this is a little high - good luck typing in the backtick in your login password in a Japanese locale etc. But if we say 95, that's (a littler more than) log2(95)~6.569 bits per character. So you'd need a 10-character string for 64 bits. And that string would look like: jIg@T>L+b_

While that can be memorized for typing, how long will you be able to remember it? What if you have to change it semi-frequently? And how about the 128 bit version?: %w}Wf#O"]#z@eAwI@\'gK

[1] '!"#$%&'()+,-./:;<=>?@[\]^_`{|}~' + * (on the outside due to hn formatting)

Mixing up authentication and identification is a mistake, I think.

Biometric authentication is not meant to be an increase in security. It is meant to be, and is, an increase in convenience. Since convenience and security are fundamentally opposed, this allows security to be increased in other ways while keeping the present balance for users.

A better title for the article: "Google wants to replace your password with the analysis of your private life".

Of course, since it's always running in the background, you can be sure it will be (ab)used for way more than passwords.

And I know a lot of people that will let them do it.

And that depresses me.

s/better/more click-baity

Please let's don't encourage the buzzfeedification of everything, maybe?

https://twitter.com/f_u_e_n_t_e/status/706462603401412608

"A... fingerprint... is... a... username... not.. a.. password... There. I can't say it any slower."

Biometrics should not replace passwords. Ever. They serve different purposes.

The problem with biometrics is its a password you cant change. What happens if theres a leak? Unfortunately we can't update our facial structure.

This kind of API might be useful as a 2fa, but never as a standalone authentication mechanism.

Edit: I mispoke. The main problem isn't with leaks, its with other apps collect the same data google uses as biometrics. For example, a video chat app that grabs the same biometric data (facial structure/typing pattern) that google uses for authentication. That chat app then would have everything needed to emulate you.

> What happens if theres a leak?

I didn't even think of this. That's a very scary thought. Not only is it leaking your password replacement, but a good part of your identity.

http://www.ibtimes.co.uk/philippines-55m-voters-exposed-fing...

Google always seems to betting on several horses — for authentication, Google is also backing the FIDO U2F standard. This is basically a standard that allows you to authenticate with a physical security token, connected to your computing device via USB, NFS, or Bluetooth LTE, and reusable for as many U2F-enabled services as you like, without those services being able to correlate that device across services (so if you authenticate as user Alice at GMail, and later on authenticate as user Bob at Youtube, Google won't know you used the same U2F device due to the way keys are generated).

No need to type in some generated value (as with OTP), just press the button on the key, or swipe it past your NFC/Bluetooth LTE-enabled device to authenticate. Logins can be optionally strengthened with a weak knowledge-factor such as a PIN.

It already works in Chrome, it will be supported in Firefox and probable Edge at some point, and you can choose which manufacturer you want (e.g., Yubico).

I really hope U2F gains traction, because biometrics really creep me out (in addition to the many arguments against its use mentioned in this thread).

The goal is great, yeah! But the solution is very, very wrong. You don't want to authenticate with a key that you can't change.

E.g. someone copies your face with a 3D printer and you find out. You want to be able to stop him from accessing your secrets. But you don't want to apply plastic surgery for that.

Second e.g. someone captures you and wants to open something you can only access with a part of your body (like a finger, or a face or an eye). In that case you want to be able to give it to him without him cutting off parts of your body. The security is broken, but at least your body doesn't have to be. So yeah, this solution is very very wrong. (It's weird that the physical key has the attribute that someone can steal it is in some cases a feature not a bug, but if you think about it it's true.)

Google can't kill passwords, they can simply make it more convenient to login for users like TouchID. Biometrics should simply be an additional part of 2 factor authentication. Finger prints are something we have, passwords are something we know. Police or criminal or a partner could simply put your thumb on your phone to login into it without your consent (or knowledge if you are asleep). Where is people without arms, hands or lose or damage them later in life wouldn't work. Passwords are compromised all the time but you can simply change it. If your fingerprint is stolen eventually you have no realistic option to change it. Biometrics should simply be an additional layer of security as it is today.

  '...average of over 100 passwords in Europe'

I'm truly fascinated at this number; if I understood it correctly that means you are registered to at least 100 services that you semi-actively use, AND have different passwords for all.

Not even the people I know who generate randomised passwords have more than 20 they use regularly.

Is it an exaggeration or a realistic figure?

I don't know about other people, but I have well over 1,500 accounts on various sites, probably about 300ish that I use on a regular (read: at least weekly) basis.

However, I use a password manager that logs in for me, as well as generating passwords. I actually don't know what 99% of my passwords are, and almost never type them.

This Trust API sounds interesting. I'm curious to see where it goes.

I use Passpack's free service which will store a maximum of 100 passwords for you. I have been at max capacity for some time now, but you're right, a lot are not used regularly and I can generally find an old one to delete when I need to add a new one.

Recently (after a friend being hacked) I changed all my passwords and unsubscribed from as many services as (confortably) possible trying to reduce my 'digital footprint'. After reduction I still have 60 accounts/passwords.. So 100 passwords is very realistic IMO.

My password manager currently has 153 passwords in it. I was surprised too once it started filling up.

My password manager has 500 entries. Around 75% of them are website passwords.

What is the remaining 25%? 125 mail accounts? :)

I propose that some of the opposition to micropayments and pay for clickbait and paywalls and such is password fatigue.

I classify my accounts as critical/financial (if someone got this it would cost money or legal problems) and don't care.

I have a handful of critical and financial passwords, but every "don't care" is the same password. If someone gets my HN password, they also pown my facebook and linkedin and random forums and sites, but those are irrelevant so I don't really care because none of that stuff matters or contains anything important. (By important I mean real world important like buy food or get medical care or whatever, in an abstract sense HN is important to me, but not nearly as important as being able to feed my kids)

I don't know what I'd do with micropayments (if someone stole this login they could steal the equivalent of a can of soda from me... should I care enough to set up and maintain and track and occasionally change a special dedicated individual password for that can of soda equiv for something like that?)

I believe this also explains the rise of Amazon. Oh man, somewaycoolstore.com won't let me check out without creating an account and keeping my credit card info (probably in plain text of course)? That sucks. I'm willing to buy the same thing from Amazon for more money because I don't have yet another account and yet another pending security breach with my CC number.

Note that some superficially "financial" sites are not risky. If someone stole my electric company login, they could... pay my bill for me? The site isn't terribly functional and I like it like that. I can only write payment methods not read payment methods, so my bank account info is perfectly safe. Their billing system thankfully isn't integrated with their customer support at all, which superficially sounds awful, but at least if someone stole my acct they couldn't enter a service disconnect order in my name. I'm pretty well off, if someone else clicked "pay bill" for me they couldn't cause bounced checks, I just have too much money for that (and/or my efficient house has bills too small to matter). I guess the worst thing someone could do to my electric company account is change my password, which would waste about 10 minutes of my time getting it reset over the phone. Its not worth the substantial operational cost of setting up a special password.

I don't need fingerprint reading and retina scanning and DNA verification to log in and click "pay" every month. A truly interesting passwordless solution would be for me to give permission to not password protect my electric bill. The "secret" data is already public and resold to every .com and .gov on the planet. A suitably intelligent protocol more complicated than "click, its done" could work. If I got push notifications of anyone including myself or wife trying to pay my bill and they didn't charge for a day or two and I could fix any "problem" in less than a day or two, I'd be happy with that.

I suspect most people who don't use a password manager reuse passwords. A lot.

If you get the password to one of my unimportant accounts, you get the password to most of them. They're unimportant, but still...

I'd vote for realistic. My password manager has nearly 100 accounts already, and I'm not even the kind of person who signs up for every random webshop or raffle.

Also a discussion from yesterday on Schneier's blog:

https://www.schneier.com/blog/archives/2016/05/google_moving...

Biometrics like TouchID work fine for authentication, but they don't work for encryption. Encryption requires a secret, and you can't really call your biometric features a secret (even besides that it probably won't be of high enough entropy and that you wouldn't be able to have more than one set). This is why iPhones always ask for your password when you restart your phone -- it's not just a security feature, it actually needs your password in order to decrypt the phone data.

I'd heard this was in the pipeline, but didn't believe it given how invasive (aka no privacy), problematic (you can't backup how you behave), and insecure (given a motivated attacker, I've yet to see a biometric control that can't be attacked).

Why's Google doing this?

It's not obvious to me, since I'm guessing they know all of this, likely already have they data on users, etc.

Why's Google doing this?

Because passwords are terrible.

Lots of users pick guessable ones unless you have extensive password rules to stop them, and those rules are a huge pain to your users.

Lots of users have terrible password hygiene, leaving them all sorts of places they shouldn't.

Enough users are going to forget their passwords that you need a recovery mechanism. Which means an attacker needs to break either the password or the recovery. The most common recovery method is email, but Google often is the email provider.

My understanding is that this was deployed internally first, so the calm that "people" don't get passwords seems like a stretch.

(Meaning I assume that the average person working at Google is smart enough to know how to use passwords.)

Knowing how and putting it into practice are two different things.

I know I should eat better and exercise more, and yet here I am eating a scone and not having been on my bike in nearly a month.

Because they'll log the data of who logs into what, when, then sell it.

So you want your adwords for a new website called "frameworkoftheweek.com" (which surprisingly is not registered at this instant) to only appear to people who log into HN at least once per week because they'd be the ideal target market. And google says "OK we can do that".

Or you own a local supermarket and you want your adwords for "cucumbers on sale" or whatever to appear ONLY to people to log into your local hometown newspaper, because they almost certainly live there. Heck why not try the logical union operation of the local hometown newspaper, every small local bank and credit union, anything else that's local and has an account system.

In a way I'm not bothered. 99% of ads are useless to me so I block them. These ads might actually be useful to me. Ads that don't suck are an interesting thing to think about. Of course we've been promised that everything from the blink tag to popups was the magic bullet that would make ads not suck, yet they sucked anyway.

What about your ability to refuse to tell law enforcement a password? In the U.S. at least there is some precedent that giving a password could be a self-incriminating act, so you can be protected under the Fifth Amendment. I wonder if biometrics to unlock a device would count as an "act". If not, people could be forced by courts to hand over their passwords.

I still think there's a need for passwords depending on the context. For example I would worry if Google employees didn't encrypt their work laptop with FDE as there are very motivated people who super want access (even a tiny slither will do) to Google's internal infra.

Google has enough dirt on people anyway to implement a passwordless system because they practice very rigorous fingerprinting of individuals regardless. You don't even need a Google account. Google knows who you are as you traverse the web in any meaningful way. They do this through fingerprinting captchas / supercookies, and subsidizing core internet infra like Blogger, any number of vanity URLs (goo.gl), and they have others at their disposal.

But do note: Google are not 'too big to fail' like a bank.

The great Alphabet Leak of 2030 is upon us and we better be ready.

> 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

Helpful of them to give everybody trying to break this a measure of how well they are doing. Much easier to optimize against than a binary succeed/fail.

"Consumers tell us that they are struggling to remember what is now an average of over 100 passwords in Europe."

This is what needs to be fixed; there is no reason for most people to remember more than two passwords for personal use, one or two more for work in some cases, and maybe a few more in special circumstances. Decades of encouraging (or legislating in some cases[1]) users to do the wrong thing makes people hate passwords.

[1] Apparently in the US medical patient portals are required to (attempt to) prevent you from storing your password in your web browser.

>This is what needs to be fixed; there is no reason for most people to remember more than two passwords for personal use, one or two more for work in some cases, and maybe a few more in special circumstances. Decades of encouraging (or legislating in some cases[1]) users to do the wrong thing makes people hate passwords.

I'd argue there is no point for any person to remember more than 2 passwords. That is what password managers are for. One master password and you don't know your other passwords. Those are randomly generated for security (pick a password manager capable of generating pattern-matching passwords for places with terrible password policies).

>[1] Apparently in the US medical patient portals are required to (attempt to) prevent you from storing your password in your web browser.

HIPAA concern. If credentials are stored someone could login as the patient and view their details.

> Biometric authentication is a powerful enabler, allowing businesses smart enough to deploy it to significantly increase rates of registration, gaining data and insight about their customers, while also increasing customer security. This is a win/win scenario which sounds the death-knell for awkward and insecure passwords sooner than we may imagine.

More unwarranted data-gathering.

I really want to like this idea, because I so very hate passwords, but until there's a method that I have complete control over without the cost of my privacy, I'll be opting out.

This sounds pretty good from a user experience perspective, as long as there's a fallback method (click "can't log in" to send a text to my phone etc.).

If I die or am otherwise incapacitated, and my wife needs to access my accounts, she'll want to get my passwords from the safe (she's not great at remembering them). Biometrics is useless for this case, though maybe she can use the phone text fallback. It all sounds a little iffy, but then, passwords are iffy as well.

> 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.

I get the feeling that early adopters of this would end up erring on the side of more confidence and still ask for "old-style" passwords. So basically, 2fa on a more widespread/intrusive scale.

"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."

No thank you, no. I think now is the time to realise, that Google is really building the all-seeing eye - and by forcing this stuff, they will eventually get it.

If the reason for this is too many passwords, the answer is a central auth service, not new auth factors. They should be working on a privacy-oriented protocol and network, not making yet another independent auth mechanism.

Not to mention this only works for smartphones! What happens when I need to log in at Kinko's?

>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

So when I'm nervous I can't log in?

It'll probably know when you're nervous and maybe place an ad for a sedative in your Facebook or Twitter feed? Or maybe sth like a "who's nervous around" screen on someone's phone will show your name on it. It's really discomforting this thing, there's an infinite possibility of exploitation.

I think we are all looking at this as too much of a zero-sum between privacy and security and ease of use.

What if we did away with passwords in 90% of use cases but required validation to change account settings, like email addresses?

I think the aim of this project is misguided. Next to the many excellent points that have been raised in response to this article, there's one that I think is a killer for its practicality, based on the article below (which was featured a few weeks back):

http://motherboard.vice.com/read/lego-driven-robot-programme...

I think techniques such as used in the above article, that create "ultra-generic power-user" of the users of a device, will be quite difficult to protect against through measures such as announced by Google with Trust API.

The Lego robot from the above article could only be effective because it knew their user's swiping pattern, without this knowledge, the model would have failed miserably, in a very easy binary decision (is the pattern equal to the original pattern). Now that Google is effectively making everyone's "swiping pattern" uniform, these techniques will become a lot more effective. Not only in the test phase, but the training phase as well. The ultra-generic power user model was derived from 41 users who each had different swiping patterns. To me, it seems that this would be made a lot easier if every user had the same pattern.

A Biometric classifier for a person A tries to distinguish between behaviour that did come from person A, and behaviour that did not come from person A. This, in one way, can be seen as measuring the distance in some highly dimensional behavioural space between the average/nearest of all data points that DO belong to person A, and balancing that against the distance between the average/nearest of all points that DO NOT belong to Person A. Presumably, ultra-generic users are somewhere in the middle on this and muddle the water a lot. These ultra-generic users are likely much closer to A then a random person who is not A will be. Best of all, unless in the unlikely case that person A is a super special snowflake, the model can be trained offline, on persons who are not even A!

So in order for person A to be able to sufficiently distinguish itself from ultra-generic power user B, A needs to have a secret password again..

This is great for the large numbers of people who don't understand the concept that any form of biometrics is a means of identification, not a password.

I could see this used as part of 2FA, if you don't mind giving away even more of your privacy, but I will never use it.

As always biometrics are more secure usernames, not passwords.

Does it work on twins?

Reply on news.ycombinator.com