
Government launches login.gov to simplify access to public services - skybrian
https://18f.gsa.gov/2017/08/22/government-launches-login-gov/
======
pdabbadabba
This appears valuable and well executed, but I worry that private businesses
will be eager to outsource their authentication to this service, if they are
allowed to. And once it's fully stood up, I suspect the government would be
all too eager to oblige.

This might be convenient, but might also mark the beginning of a major new
point of U.S. government control over the Internet, with all the surveillance
and other civil liberties issues that this might raise, to say nothing of the
issues that could arise from this degree of centralization.

Now seems like the time to set the expectation that this service may not ever
be used by private websites. Of course, we tried that with Social Security
numbers too, for all the good it did us.
[http://www.nytimes.com/1998/07/26/weekinreview/the-nation-
no...](http://www.nytimes.com/1998/07/26/weekinreview/the-nation-not-for-
identification-purposes-just-kidding.html?mcubz=1)

~~~
spencerhakim
Given the alternative of handing out my SSN and hoping for the best, I'd be
more than happy to use this for banking and related services. Presumably,
third-party use would be covered by some form of ToS, and maybe we'd see
actual repercussions for leaking data that originated here.

~~~
gumby
Even if you're not concerned that the government might get a list of all the
sites you log into, what about arbitrary login _revocation_? Suddenly someone
gets a brain fart and decides that everyone on the terrorist watch list
shouldn't be able to use this service? Now you're locked out of all the
accounts you used this for, even if you're not a "bad guy".

This is why I don't use "log in with google" or log in with Facebook" \-- I
don't think those companies are evil (I use them both) but I can't afford for
them to accidentally or absentmindedly deny me access to other services.

~~~
Buge
With the government you have free speech rights, so you can sue them if they
close your account. With private companies you have no free speech rights and
they can close your account whenever they want.

So account closure seems like a positive point of government-controlled login.

~~~
gumby
Look up the secrecy and lack of oversight over the so-called "terrorist"
watchlist and the calls for scope creep, and see if you are so confident about
those first amendment rights. I'm sure failure to log in would not be
considered a first amendment right.

I agree that the government should be a far more dependable provider than any
private sector organization. But the recent (last 20 years) enthusiasm for
scope creep has not been encouraging.

~~~
Buge
Does the government deny passports or driver licenses/IDs to people on those
lists? Because that would be the equivalent here.

I'm not saying the government wouldn't do it. I'm saying you would have
constitutional basis to sue, which you don't have for companies.

Some lawsuits against the no fly list have been successful.
[https://www.aclu.org/blog/national-security/victory-no-
fly-l...](https://www.aclu.org/blog/national-security/victory-no-fly-list-
process-ruled-unconstitutional?redirect=blog/victory-no-fly-list-process-
ruled-unconstitutional)

~~~
bluesroo
I'm not sure that it would be seen as equivalent here given the overall push
away from net neutrality over the last decade. I could see many government
officials making the (out-dated) argument that the internet is a non-essential
service and you online profiles are not as critical as physical government-
issues IDs.

Edit: Forgot this post was a couple days old, working through my HN backlog
haha

------
jrminton
Thanks for all of the passionate comments on login.gov!

First, my name is Joel Minton and I lead login.gov. All of us who came here to
build this did so to drive higher Security, Privacy and Usability for all
Americans. This is a core building block that we believe will benefit millions
of Americans and the government agencies that serve them.

Second, the tradeoffs that we have been considering for over 18 months are
very similar to those that all of you are bringing up as well. We have made a
lot of progress on balancing these tradeoffs, which are primarily focused on
Security, Privacy and Usability. Since we are constantly iterating to improve
login.gov, we welcome any future feedback that you and others provide.

Third, for anyone who has a background in identity and/or large scale
platforms and is interested in serving our country by helping to build this
critical platform, please consider joining us. Your salary would not likely be
as high as the private sector, but trust me, the amount of positive impact you
would have on our country is tremendous. You can DM me either on Linked In or
my lightly used twitter Account (jrminton).

Thanks again!

------
rhencke
For those interested, development is done in the open here:

[https://github.com/18F/identity-idp](https://github.com/18F/identity-idp)

~~~
raarts
But issues opened remain unanswered..

~~~
rhencke
I opened an issue. They answered it.

4 out of 5 open issues have comments from core members working with the issue
opener.

Seems ok?

------
throwawaythrow1
It's interesting that no one here has yet mentioned the UK government system
"Verify". Fundamentally there are different authentication mechanisms and
idealogies at work, but it's the same UK CESG GPG implementation as Verify. I
genuinely wonder if the US people understand the privacy implications of a
central authenticating party as opposed to many federated ones?

~~~
Edmond
Yeah I think USDS is taking motivation from Verify.

I actually contacted the Verify folks about leveraging a privacy-preserving
approached as outlined here:
[https://www.cipheredtrust.com/doc/](https://www.cipheredtrust.com/doc/)

I believe they were involved in some sort of porn regulation effort launched
in the house of commons with a lot of privacy implication, a mechanism as
described above would address all of that privacy problem.

~~~
toomuchtodo
USDS does take motivation from and works with the UK version of the USDS.

Source: Interviewed with USDS.

------
forforthought
Given that this is a typical identity provider, I'm curious there's interest
to make this service available to the saas industry at large.

For example, I'd rather NOT have to manage login credentials for my bank,
mortgage car payment, and various airlines.

I'd rather let login.gov handle it.

Moreover, as a saas provider, I wouldn't mind deferring this liability to
someone other than google or facebook.

~~~
Micoloth
To me, this is the right attitude towards this. Really? Are you more scared by
your own democratic government than by facebook?

Besides i'm not even american, so whatever

~~~
barsonme
Well, yeah. I can choose to not use Facebook (for the most part). I can't
choose to not use the federal government.

Plus, disliking and being wary of government is quintessentially American—it
goes back to our roots as a country.

As an example that just popped into my head, look at DACA: a bunch of
undocumented persons told the federal government about their undocumented
status (in exchange for something good) and now that information can/will/may
be used to deport them.

With the government, it cuts both ways.

~~~
zbentley
Those are valid points, but I think they miss the point of the question: are
you more scared _about data security in an online identity provider_ provided
by the government or Facebook et. al.?

Your answers were more about things the government can do to screw you over.
It can do those things if your data is stored in Facebook as well: search
warrants, compliance orders, subpoenas, etc. will all result in the government
having access to your data unless strong encryption is used on your data
(which, as we've seen with Apple, is still not enough sometimes).

I think (though I may be wrong) that the question had more to do with whether
you trust this solution to be more secure against external/accidental breach
than a solution offered by Facebook. I don't know the answer to that question,
though.

~~~
mdpopescu
The point is, a warrant is a tiny bit more difficult to get than no warrant.
Having all that data on their own site bypasses the need for one.

~~~
zbentley
True, but having all the data on the government's site may ( _may_ ) make it
more secure from being leaked to sources other than the government. This isn't
a statement of the government's software quality, but one of incentives: large
private companies have not, historically, suffered much (legally or in terms
of growth/revenue) from data breaches. The government losing data that it has
independent reasons to keep safe is probably a larger perceptual risks, since
government departments/funding can be suddenly cut in the wake of disasters of
this nature, and elections can be lost. TL;DR the feedback loop for bad
security might be more direct if the government is the one doing the securing.
That's a troublesome prospect in several regards, but is plausible, I think.

------
jeremyevans
In case you are wondering how it handles password encryption and storage, it
appears to use a custom password hash based on SHA256 and scrypt:
[https://github.com/18F/identity-
idp/blob/980c2aa26397f530673...](https://github.com/18F/identity-
idp/blob/980c2aa26397f530673e009a8370019ab3330b54/app/services/user_access_key.rb)

Passwords appear to be stored in the users table in the "encrypted_password"
column, and it does not appear that any database-based security is used. This
is one RCE/SQLI vulnerability away from exposing the password hashes for all
users. To be fair, that's probably true of most sites that store password
hashes, but I would have expected better from 18F.

~~~
dangero
what is database-based security?

~~~
Maarten88
It's an old craft that died somewhere around the dotcom hype in 2000.

It works with SQL, using language elements like VIEW, PROCEDURE, ROLE and
GRANT

SQL Databases can still do it, but people who know how to use it are all
retired or work in management now. :-)

Also: no web framework knows how to deal with it.

------
djwbrown
Impressive response to the HealthCare.gov fiasco:
[https://en.wikipedia.org/wiki/18F](https://en.wikipedia.org/wiki/18F) Some
other interesting projects here:
[https://github.com/18f](https://github.com/18f)

~~~
andrefrancisco
Our repos can be a lot to wade through. You can see examples of our specific
projects here [https://18f.gsa.gov/what-we-deliver/](https://18f.gsa.gov/what-
we-deliver/) (and each project links to the right repos if you want to see the
code/docs)

*I work for 18F

~~~
antimatter
I know elsewhere in the thread you mentioned that you're not on the login.gov
team but would you mind passing U2F support and removing SMS as a second-
factor auth as a feature request? Thanks :)

------
cyberferret
Hopefully the US government will do better than the awful AUSKEY system that
the Australian Government designed. Every time I upgrade my PC or notebook, I
have to download a ton of Java crud, not to mention certificates, in order to
be able to use it, and even then I have constant browser issues with
particular versions of Java or certificate chains being misconfigured.

Unfortunately, I _have_ to use AUSKEY to transact on my business tax details
etc., and just the sheer UX nightmare that it is makes an already detested
task even harder to swallow.

~~~
inopinatus
For most ATO business dealings there is support for a myGov login now. I was
very relieved to retire all the AUSKEY crap.

------
latchkey
A total nit pick, but why do people have such a hard time consistently naming
something as simple as a boolean variable? If we remember that naming is one
of the hardest things in software engineering, why don't we put more thought
into it?

From the documentation in the README: [https://github.com/18F/identity-
idp](https://github.com/18F/identity-idp)

    
    
      disable_email_sending: ‘true’
      enable_load_testing_mode: ‘true’
      telephony_disabled: ‘true’
    

Multiple directions, multiple naming conventions, strings?!?!?. Just seems
like a recipe for failure. I feel like this would be more clear:

    
    
      load_testing_mode: true
      send_email: false
      telephony: false
    

When you write your conditionals, it makes it so much easier to read:

    
    
      if !disable_email_sending
         do_send_email
    

vs.

    
    
      if send_email
        do_send_email
    

Here is the line in actual use...

[https://github.com/18F/identity-
idp/blob/df549cf9a1fc2c21e3e...](https://github.com/18F/identity-
idp/blob/df549cf9a1fc2c21e3e322fa10e762ccb07da2a9/config/environments/production.rb#L23)

I'd personally rather have the positive condition first as it is easier for me
to follow logically in my head.

~~~
mdpopescu
I agree with having positive names in booleans (email_enabled vs
disable_email_sending), but not with having verbs as booleans. send_email is
an action; the corresponding flag should be email_enabled or is_email_enabled.

------
currydove
just signed up. Service is a little wonky, but they've introduced 2FA via SMS
and Authenticators as well! Thankfully not just SMS.

They also make you download/print a private key just in case.

------
scott00
Created an account. It asks for and confirms email and phone number.
Interestingly it does not ask for name or SSN. So it doesn't really represent
an identity as a person but rather as a recipient of communications.

Security-wise, starts with using the phone for 2fa, allows setting up TOTP.
Generates backup codes and tests for retention. Big problem though: there's no
option to disable the phone as a 2fa option. A lesser sin is no U2F support.

------
gitchanhub
We have a similar service in Hungary since 2005.

I wonder why something like this was not a thing in the US before? I mean we
are not a 3rd world country but definitly behind the US in almost every
aspect. Is it something to do with the relationship between the states and the
federal government?

~~~
TulliusCicero
The US is backwards in plenty of ways, honestly, and the government is
frequently a good (bad?) example. Moved to Germany a year ago, the government
just seems so competent and drama-free here in comparison.

~~~
ihattendorf
Wasn't it Germany that had the electronic voting machines compromised?

~~~
germanier
Not a voting machine (we don't have any) but software used to tabulate
preliminary results was shown to be vulnerable. Honestly, this is pretty bad
but not "voting machines compromised" bad.

------
jasonjayr
login.gov is using "Let's Encrypt", which is kinda awesome :)

Should they have used an EV certificate?

~~~
mholt
Nah. DV gives you the same cryptographic guarantees, but with the benefit of
100% automation.

~~~
chipperyman573
To add to this, a US government site does not need this, because only the US
government site can register a .gov domain.

~~~
nilved
They can be taken over.

~~~
zbentley
In which case EV wouldn't get you anything, right (since presumably it would
be verified and issued before the site was taken over)?

------
weddpros
Why it's a privacy nightmare: you _delegate_ authentication to an oauth
service. You trust it to check the authenticity of the login/password.

The code is open source, but it doesn't mean login.gov runs exactly this code.

Now imagine the NSA forks the code, adds a master password
"IworkForTheNSA,LetMeIn!" and runs the fork instead on login.gov. Now the
government can impersonate you in seconds.

Use Auth0 if you don't want to handle auth yourself. It's probably more
difficult to coerce a private company into hacking its users, than it is for
the NSA/FBI/IRS/Whatever to hack it's own system.

Don't be foolish. Don't use that for private businesses.

~~~
bobthecowboy
> It's probably more difficult to coerce a private company into hacking its
> users, than it is for the NSA/FBI/IRS/Whatever to hack it's own system.

This is a fantasy. I'm shocked to find people parroting this argument mere
years after Snowden.

~~~
weddpros
Don't you think it's easier for the government to hack its own code than
someone else's ?

~~~
zbentley
Maybe, but where "hacking someone else's" might just be issuing a search
warrant, the difference in difficulties is like the difference between
swatting a mosquito and swatting a gnat.

------
whalesalad
Ironic that [https://login.gov](https://login.gov) does not have a login form
located anywhere on it. Just a teeny and hard-to-notice "Manage Account" text
link in the corner.

~~~
rhencke
Consider this may be on purpose:

    
    
        Not all information requires an identity system to manage
        access. You can protect the privacy of users and reduce
        the security risk to your systems by avoiding any
        unnecessary collection of personally identifiable
        information — this even includes contact details.

------
ocdtrekkie
This is kinda cool, but it's also a little concerning. One of the ways our
government protects our privacy is specifically by not centralizing
information. Just because you pay taxes or have healthcare doesn't mean the
police has that info, for example. The efficiency of connecting a large number
of governmental agencies to a single account for you is pretty concerning, it
puts all the data in one spot that can be extremely tempting to access.

~~~
oh_sigh
I know I'm not supposed to say this, but you obviously either didn't read the
article or read it but didn't understand it, and perhaps you would be better
off reading it more closely before commenting. The article lays out that this
is not centralizing information, but is merely allowing a bunch of different
agencies to use it as an identity provider.

The same way I can, say, connect to my spotify via my Google+ account, but
that doesn't mean that google has all of my spotify playlists.

~~~
grzm
> _I know I 'm not supposed to say this, but you obviously either didn't read
> the article_

If you're referring to the guidelines, they also show how leaving out
sentiments like these doesn't diminish the clarification you're adding:

> _Please don 't insinuate that someone hasn't read an article. "Did you even
> read the article? It mentions that" can be shortened to "The article
> mentions that."_[0]

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

Chiding someone who is trolling isn't going to accomplish anything (and likely
make it worse). If they aren't, they'll (hopefully) appreciate the
clarification, no chiding necessary.

~~~
oh_sigh
Perhaps the gentle chiding will encourage people to read the article before
commenting in the future?

------
mizzao
This looks promising.

I'm currently in Denmark and they have this inane two-factor authentication
system for all (e.g. banks and not just public) services that uses physical
printed cards with 150 codes each; when you are close to using one up you need
to get another one in the mail.
[https://en.wikipedia.org/wiki/NemID](https://en.wikipedia.org/wiki/NemID)

Hopefully if this requires 2FA it can use the TOTP open standard, etc.

~~~
Erwin
You can buy a digital keyring to show the code if you want, e.g.
[https://www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-til-
pri...](https://www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-til-
private/n%C3%B8gleviser) \-- which has a limited lifetime battery; I don't
check my account often enough so I'm not bothered with the paper card.

------
hboon
Singapore launched SingPass in the early 2000s. There was a breach a few years
ago and they have since implemented 2FA.

It's really convenient, but scary at the same time.

------
tvanantwerp
I'm getting "Oops, something went wrong" for nearly everything I do to create
an account. Took two or three tries to get my password correctly set. Then I
was given the prompt to add my phone number, but got another error and ended
up signed out again. Definitely needs some work.

------
d1ffuz0r
Good to see where governments are going with tech. In Russia we've had similar
tools available for a few years [https://pypi.python.org/pypi/esia-
connector/0.1](https://pypi.python.org/pypi/esia-connector/0.1)

------
marsrover
Why is it that of all services I'm scared to actually register and log in to,
this is at the top?

~~~
slackoverflower
Maybe you don't have trust in the people that run the current government, just
like a good portion of the American population do.

------
teuna
France has something similar called franceconnect:
[https://franceconnect.gouv.fr](https://franceconnect.gouv.fr)

------
zaroth
Login Spec Here: [https://github.com/18F/identity-
idp/blob/master/docs/encrypt...](https://github.com/18F/identity-
idp/blob/master/docs/encryption-and-key-rotation.md)

Many aspects of this make no sense to me... so _IF_ this is actually what they
are doing...

    
    
      hash(user, password) {
        salt = CS-PRNG(160bit)
        s = scrypt(salt, password)
        z1 = s[0:32]
        z2 = s[32:64]
    
        R = CS-PRNG(256bit)
        d = HSM(R) XOR (pad_right(z1, 0x00, 32 bytes))
        cek = SHA256(z2 || d)
        hash = SHA256(cek)
        save_record(user, d, salt, hash)
      }
    

First and foremost, if the HSM operation is to have any _meaning_ , it needs
to be in the critical path for encrypting / decrypting data and possibly also
calculating the password hash. If you don't need to go through the HSM to
perform a decrypt or a hash validation, then obviously the HSM isn't actually
securing anything! All it becomes is a source of entropy into the key
derivation, but that's more likely to harm than help.

From their own specification;

"It is important to note that the HSM factor strengthens the model in a way
different than the other two factors, which rely on keeping them secret.
Because the HSM is tied to a physical object, brute force attacks on our
database would need to happen in proximity to the HSM, i.e., within our AWS
environment, which greatly reduces the attack surface. A bad actor with a copy
of the database cannot apply their own computing power to brute force cracking
of passwords."

But to be clear, if you have 'd', 'salt', and 'hash', you can brute force
attack passwords as;

    
    
      s = scrypt(salt, password)
      h = SHA256(SHA256(s[32:64] || d))
      h =? hash
    

Now, if they were _not_ storing 'd' in the user record, you might think to
store what they call 'R' in the user record. Then you would have to go through
the HSM as part of each login to _derive_ the correct 'd' and 'cek' which is
how it's _supposed to work_.

But even that design is still not good enough. You don't want to allow an
attacker to pull 'R' from your database, send it through the HSM just once,
and _then_ be able to start brute forcing the password forever from there on
out. If you're going to pay for an HSM, and your going to call it for each
password verification, then you better make sure an _attacker_ is also
required to call the HSM for _each attempt_ at verifying a password. Which
means you send your password hash (or something derived from it) through the
HSM, not just a random 'R'!

Next, besides all of that, the design is horrific for end users. PII is
encrypted with 'cek' above. That means if you lose your password, you lose
your PII. Which means starting basically a new account from scratch! I can't
endorse the idea that a password reset from an end user will effectively _wipe
out_ their account information and make them start over.

The vast majority of users will be logging into this service _infrequently_.
Combine this with a typically user hostile password policy, and the result is
that a large percentage of users will be resetting their password every time
they need to login. With this design, that means they have to _start over_
with validation through a third party... and guess who that third party is?
Companies like _Equifax_ now responsible for the single largest PII breach in
American history.

Now they've also added something like a recovery key which the user is
supposed to _print out and save_ at the moment they create their account, and
that key is used to separately encrypt all the PII. So if the user forgets
their password but can find this magic piece of paper, they can enter this key
(that'll be fun) as part of the password reset process and reset their
password without effectively wiping their account. To think "Average Users"
will succeed in doing this belies reality.

But wait... where is this magic key being saved on login.gov servers? If it
was a private key they give to the user and they just keep the public key on
their side that could work, but it's actually an uppercase 16 character
alphanumeric token... 5.17 * 16 = 82 bits. Let's hope that's not literally the
encryption key, but the alternative -- it's a token used to lookup the key in
their database -- would completely defeat the purpose of encrypting the PII
with a PBK in the first place?! And, even if it was the literal encryption
key, when you change or update your PII, if they don't also keep it on their
side, how would they update their secondary encrypted PII record?

~~~
pfg
> Let's hope that's not literally the encryption key, but the alternative --
> it's a token used to lookup the key in their database -- would completely
> defeat the purpose of encrypting the PII with a PBK in the first place?!
> And, even if it was the literal encryption key, when you change or update
> your PII, if they don't also keep it on their side, how would they update
> their secondary encrypted PII record?

Without having looked at the actual implementation, here's one option that
could work: Upon account creation, the server generates a key pair and a
random string - the recovery code. The server stores the public key and an
encrypted version of the private key, with the encryption key being the
recovery code. Any changes to PII can be encrypted using the public key. The
server does not need to store the recovery code (which would beat the whole
point of this exercise). Instead, it can simply attempt to decrypt the PII
with the user-provided recovery code, and if it succeeds, the server knows the
entered recovery code was valid.

~~~
zaroth
This would indeed work! I'm still studying their code for handling the
recovery key, but as of yet I haven't found any asymmetric encryption of PII.

It does look like they are using the recovery key as a second password, and
running it through scrypt to verify it, but I haven't traced past that point
yet, and Ruby is not my first, second, or 3rd language.

From what I can tell, they do the same key derivation process as with the
primary password, but then also encrypt the secondary 'cek' with another key
-- perhaps just HSM(R) -- so they can get back 'cek' without needing the
token. But I'm not sure I'm reading it right because there are variables
called things like 'encryption_key', 'encrypted_code', 'encryption_code',
'encrypted_key', 'encrypted_password', 'personal_code', 'raw_personal_code',
'code', 'hashed_code', ahhhh.....

If there's one good thing to say about all this, the fact it's open source and
I can even look at it all, and open issues on GitHub against the US
Government's code for authenticating citizens... well just that is pretty
awesome.

------
pteredactyl
Does this mean I'll be able to regenerate my SSN?

------
donatj
There's a lot of very positive comments about this, but I don't understand why
anyone would want this?

It seems very big brother-ish to me.

------
ProAm
I would not trust our government to implement this safely, efficiently or
well.

~~~
dkhenry
You don't have to trust them. Its open source

    
    
      https://github.com/18F/identity-idp

~~~
nilved
There's still a _lot_ of trust involved here...

------
snambi
nice. SSO for govt. why not?

------
korzun
> Also, security experts protect one service instead of many. Dedicated teams
> of design and security experts also will continuously improve it.

I don't buy it.

------
briankwest
The Government equivalent of Equifax. YAY!

