
Google will begin testing password-free login to Android apps - jonbaer
https://www.theguardian.com/technology/2016/may/24/google-passwords-android
======
konschubert
> 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.

~~~
thomnottom
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).

~~~
eevilspock
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.”_

~~~
jimktrains2
> 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!

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

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

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

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

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

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

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

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

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

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

~~~
e12e
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!

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

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

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

~~~
Godel_unicode
s/better/more click-baity

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

------
pmlnr
[https://twitter.com/f_u_e_n_t_e/status/706462603401412608](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.

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

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

~~~
kristofferR
[http://www.ibtimes.co.uk/philippines-55m-voters-exposed-
fing...](http://www.ibtimes.co.uk/philippines-55m-voters-exposed-fingerprint-
passport-data-stolen-1553720)

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

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

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

------
grenoire

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

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

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

------
mikegerwitz
Also a discussion from yesterday on Schneier's blog:

[https://www.schneier.com/blog/archives/2016/05/google_moving...](https://www.schneier.com/blog/archives/2016/05/google_moving_f.html)

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

------
nxzero
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?

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

~~~
nxzero
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.)

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

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

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

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

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

~~~
Nadya
_> 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.

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

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

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

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

------
peterwwillis
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?

------
Kristine1975
_> 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?

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

------
rm_-rf_slash
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?

------
Phemist
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...](http://motherboard.vice.com/read/lego-driven-robot-programmed-
to-hack-touch-screen-authentication-systems)

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

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

------
warcode
As always biometrics are more secure usernames, not passwords.

------
projectramo
Does it work on twins?

