Hacker News new | comments | show | ask | jobs | submit login
Government launches login.gov to simplify access to public services (gsa.gov)
258 points by skybrian 100 days ago | hide | past | web | favorite | 163 comments



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


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.


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.


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.


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.


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


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


Government action could let you sue under (say ) free speech protections.

You can't sue FB for account termination


Repercussions? For the OPM hack, I got a form letter and a year (I think, I didn't use it) of credit monitoring. That was some of my most intimate information. That was a huge invasion of my privacy. I didn't even get a phone call. I didn't even get a sincere apology.


Just as an FYI, I think they extended the period to 10 years. I agree that it was handled poorly!


I froze my credit. I am in a position where I don't need credit and can get credit by virtue of assets if I did need to. I was, for lack of a better phrase, pretty pissed off. I got a form letter and something about credit monitoring in one of those weird security envelopes, as I recall.

Ten years? Yeah, that'll help. I pretty much admitted to everything I'd ever done, on those forms. It wasn't just me impacted, it had names of my friends and family. Then, I'm guessing it had all the notes I didn't see, from things like the interviews.

I don't have any real enemies, or any reason to be afraid, but that makes me no less angry and feel no less violated. Meh... I try to let the anger go, so it only pops up when I discuss it. There's nothing I can do to change it. I do consider it the greatest violation of trust ever enacted on me by the government. There was no reason for me to even be in the system any more, I am retired.

[redacted]

Oh well... If you can get away with it, freeze your credit. This does, curiously, impact your credit score. The peace of mind is worth it. Sorry for the novella.


This thread is the digital equivalent of why every attempt so far to set up a sane ID system in the US has floundered, leaving us stuck with the worst possible solution, SSNs.


Wouldn't it be entertaining if the SSN leak was just a really clever PR boost for the Trump administration?

I'm certainly entertaining conspiracy theory level ludicrousy, but it is entertaining.


The EquiFax thing would only be good PR for Trump's administration if they used it as an attempt to push through legislation that would prevent these kinds of things from happening in future - like a reasoned and functional (and minimum privilege) national identification service - while Alex Jones-types would normally be up in arms I think they would support it it Trump sold it as the system additionally to make it easy to identify illegal immigrants and members of the "alt-left".


In many countries (e.g. Denmark), this is already the case.

https://en.wikipedia.org/wiki/NemID


But do these countries have the same laws, processes like the USA? If not, there's no point in mentioning some other country has it.

For example, in Norway you can see everyone's tax returns [0]. The caveat is that if you see someone else's tax return - the person will be notified. Now, if you just make tax returns public without the notification - it would be a different policy and not comparable to Norway. Therefore, comparisons/mentions should be complete and apt.

[0] https://www.theguardian.com/money/blog/2016/apr/11/when-it-c...


Netherlands has DigiD. Banks here are rolling out iDIN which can be used to authenticate elsewhere as well. Banks here have been using TOTP for ages for online banking, with a physical authenticator. Tho iDIN is more recent.

Belgium has eID.


This is part of the reason why I see value in something like BlockOne ID (by Thomson-Reuters)[0].

I think it's a noble pursuit (what the US Digital Service is trying to do here[1]), making the internet easier and more accessible for people. For many people, involving themselves in the constant updates of what service is secure versus what service is not and "I have to sign up for a different email now to log in to the thing I used to log in to" is a nightmare -- and this isn't restricted to the elderly.

I think it's noble, because I really think it shouldn't be arcane. To a lot of people the nuances still are, unfortunately.

But a service that translates blockchain addresses into WWW accounts and back has some value, no? Couldn't it do a better job of this? I'd love to know if anybody has any more insight or thoughts. I haven't dug too deeply yet, but it keeps coming back to me. Perhaps BlockOne ID isn't the ultimate execution, but maybe one could be developed. Something that requires one sign up, and can be used as ubiquitously as you like.

---

[0] https://blockoneid.thomsonreuters.com/

[1] For instance, with Canadian Government services I require an account for every single service, often with different password and username requirements and age limits. I understand why, but for somebody who doesn't spend so much of their career(s) on and around and familiar with computers and how they work, it could be prohibitive.


> Now seems like the time to set the expectation that this service may not ever be used by private websites.

Wha-huh? Why? What specifically is wrong with login.gov (or any government agency) running an oauth server and private websites allowing users to authenticate with it? How does that result in "a major new point of U.S. government control over the Internet"?


It allows them to see what you log in to and thus what services you use, much like Facebook can often do as well. (Although luckily I haven't seen that as the only option anywhere yet - that might not be the case for a system that everyone in one's target audience might be forced to use.)


Tinder is Facebook-only, last I checked


It allows email now


I'm pretty certain they can already do that though.


How?


Through all the drag net surveillance the NSA performs and using tools like those unveiled by Snowden and other whistleblowers.


> Now seems like the time to set the expectation that this service may not ever be used by private websites.

Oh shit! The government knows I bought something from custom-fishing-lures.com! Ruuuuun!

Seriously, what you just listed is a reason not to use the government's Oauth for every website and ban all other implementations. What OP seemed to say, and what I disputed, is the idea that this service should not ever be used by any private website even as one of several options.


Yeah, they know you were browsing custom-fishing-lures.com on your phone just before those girls were strangled with fishing line one block away. The guy who did it wasn't using his imperial login at the time, so you're the only suspect at the moment. As long as you have a good alibi, they won't be able to hold you more than 72 hours and you should be able to get your job back.


> As long as you have a good alibi, they won't be able to hold you more than 72 hours and you should be able to get your job back.

The US does not have legally-mandated job-protected leave for pre-trial detention, people have been terminated (for cause, and so not eligible for unemployment, either) for missing one day of work due to an arrest for which no charges were ever filed.


Thanks, yes, it was the uncertainty about getting the job back that I was hinting at with "should".

BTW in case anyone thinks it was a ridiculously contrived example, I was just trying to illustrate that what one person thinks is totally innocuous can appear damning to someone else.


Don't ever trust anyone who takes your stuff at the threat of violence.


This is the basis for the "taxation is theft" argument. It's very weak and wry.

The state exists as the means for ensuring positive societal outcomes, such as providing services that the private competitive market cannot or will not supply (tragedy of the commons, game theory, etc). One such possible service is an identity service - and we already have that through a hodge-podge of things like SSN, driving licenses, passports, etc. A consolidation of these services means greater efficiency, less waste, and therefore lower taxes.

I'd respect the libertarian position more if it were framed as "greater utility of government" instead of the dogmatic "less government".


>The state exists as the means for ensuring positive societal outcomes

This is the moral basis for outcomes like, snuffing out a person for selling loose cigarettes. In the end, the privileged get away with infractions that hurt people en masse, and the disposessed get punished for offending the sensibilities of those who get to define "positivity" on behalf of society.

I'd respect the state position more if there were well defined metrics for "greater utility" and a stronger non self regulating mechanism for accountability, instead of the dogmatic principle that voting constitutes consent.


What happens when important websites start requiring login.gov, and then the government shuts down your account? Can't just sign up for a new one, can you?


Better yet. What if the government shuts off a web site's ability to utilize login.gov and effectively destroys the entire site by wiping out its userbase (in a scenario where a site is heavily using login.gov for authentication).

That's a far greater threat than that they might shut off any given person's access.

Step 1) regulate all speech by vaguely defined hate speech laws, which change based on who has power

Step 2) Start arbitrarily destroying sites based on who is in power, utilizing login.gov + speech controls, to deem a given site in violation of speech codes


> What happens when important websites start requiring login.gov, and then the government shuts down your account?

Or, more plausibly, selectively refuses to authenticate you to certain classes of sites, whether “all non-government sites” or something more targeted.


Er, why not? Why would the government shut down the account you use to identify yourself, if not because there was something wrong with it, in which case presumably they'd want you to create a new one?


I dunno, maybe one day a government-official-inspired muslim-phobia arises, and the government cuts off your access because you look like a middle-eastern man? Or maybe another flavor of the many instances of government minority-targeting we've seen in the past?

The government does shady stuff all the time. It's unwise to give them such an easy kill-switch that cuts off any particular citizen's access at any time.


I think whenever someone asks a "why would they?" question, it's best reworded as "why wouldn't they?"

The government is made up of people, and given enough people, at least one is bound to do something stupid for reasons most won't understand. If someone can do something, no matter how ridiculous, at some point, someone will.


It's bad enough when sites require you to use Facebook to log in. At least Facebook can't send you to jail and you can have (with some effort) a pseudonymous Facebook account.

Sites will use such a service to invade your privacy even further, and the government has a record of every site you've logged into and when.


> Sites will use such a service to invade your privacy even further,

That's not how OAuth works. https://en.wikipedia.org/wiki/OAuth

> the government has a record of every site you've logged into

Only the ones where you chose to use their service. Or are we imaginging a future where this service has been made mandatory, and logins and passwords have been abolished?

Honestly, the amount of FUD in this thread is absurd. The government already has an enormous amount of information about your online activity! If they want more, their strategy will probably not be writing open source software and hoping you opt in to it!


I know very well how oauth works, thanks, but I'm not sure why you thought that had anything to do with my comment. The invasion of privacy comes from websites insisting on knowing who I am and refusing to allow me to make anonymous/pseudonymous accounts. If there's a convenient API to do so provided by the government, that's bad for users.

> Only the ones where you chose to use their service.

There are hundreds of websites that require you to use Facebook to log in. With government-sanctioned ID, it will be worse.

> Or are we imaginging a future where this service has been made mandatory, and logins and passwords have been abolished?

This already exists in several countries, including Korea. https://en.m.wikipedia.org/wiki/Resident_registration_number

Hopefully this serves as an indicator that your skepticism on this topic is wildly miscalibrated. There's no "imagination" involved, this is how it is right now in places where this exists.

> their strategy will probably not be writing open source software and hoping you opt in to it!

That is the exact strategy I would use if my goal was to help the government gain more control over the internet. Letting people give their freedom away in exchange for a bit of convenience is one of the oldest tricks in the book.


> your skepticism on this topic is wildly miscalibrated

The reason I'm not worried about the government finding out which websites I visit is because they already know, from traffic inspection at the ISP level. Don't think I'm the one miscalibrated here.

Beyond that, the problem with this "but they might do something bad!" argument is not that it's false, it's that it's always true in every case. Literally every government policy could be the precursor to something terrible. Sure, they could introduce an optional OAuth to try to stop identity theft and then later use it to censor the internet, but they could also just censor the internet straightaway.


Speak for yourself. It's non-trivial (in fact, very challenging) for the government to identify which websites I use. I don't have to put in much work to make this happen. If everyone started requiring the use of a dragnet surveillance program just to log in to services, it would become next to impossible to protect yourself.


> If everyone started requiring the use of a dragnet surveillance program just to log in to services, it would become next to impossible to protect yourself.

Yes, this is true. If all websites start requiring their visitors to do something their visitors overwhelmingly don't want, the result would be something their visitors don't want. Kind of suggests that they won't do that, yes?

We will probably have to agree to disagree here; you're imagining a world where oauth.fed.gov slowly becomes more and more widespread until it's ubiquitous and we have no other options, and that just doesn't sound realistic to me. (I think it would struggle for adoption even if it were implemented perfectly and had the best privacy controls possible, due to exactly the fears you're enumerating in this discussion) But we are talking about something hypothetical, so either of us could be right.

At any rate thanks for arguing forcefully but staying respectful and on topic!


Users generally hate Facebook login but sites use it anyway because it's good for advertising and lets them outsource fraud avoidance to Facebook. The same and more benefits (to sites, not users) apply to government provided auth.

Again, please look at what's happening in South Korea. I think you're vastly underestimating how likely businesses are to adopt such a thing and how likely the government is to gradually incentivize (and eventually force) businesses into using it.


The true point of imagining the login.gov will become the defacto standard for Oauth is the same reason why Tinder was Facebook login only. It's more secure and easier for people to use when they only have one login. The consolidation of most internet logins to login.gov gives the US government more power that it shouldn't have. All you need to do is look at Google. It's not necessarily an everyday appearance, but Twitter is full of accounts of Google revoking access to accounts with no warning, and no effective or efficient way to appeal.


With the help of all the awesome new crypto algorithms isn't it possible to create a protocol for authentication via a central server without disclosing to the central server where the login goes?


It's much easier to technically enforce that this doesn't get used with private sites than tell people not to use SSNs


This is an excellent point and highlights the brutal need people of all walks have for a better authentication paradigm.


> This appears valuable and well executed

How can you tell? You are looking at a PR piece that links to a web site that mentions 'security experts' in every other sentence. It's not proven to be valuable or well executed.


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!


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

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


But issues opened remain unanswered..


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?


where can i use these login credentials?


login.gov is currently live on this app from the Customs and Border Patrol https://itunes.apple.com/us/app/cbp-jobs/id1210368989?mt=8

We're working with other agencies interested in the platform and will announce them as they go live.

*I work for 18F


Hi Andre,

Are you someone I could talk to about something like this?: https://www.cipheredtrust.com/doc/

I have sent several emails to the 18F email address without luck so far :)

The approach outlined above addresses a much larger problem, ie a way to easily and inexpensively support information verification on the internet while preserving privacy and security.


The 18F email is still the best place to go. I'm not on the login.gov team, but I can forward the link to them.


A rails app?? That's kinda awesome.


Rails app?? I’d think something go-based would be more appropriate for this kind of service.


Why? Rails powers many huge, important things.

Like GitHub.


Implementing sso idp requires pretty good crypto support - last I looked ruby, python, node don't have anything built in and use external native libraries (OpenSSL etc) that are a pain to setup and use securely.


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?


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/

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.


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

Source: Interviewed with USDS.


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.


Over the past few years, I have been conditioned to be weary of handing even more control over my personal life to the government than they already have. Assuming they open this up to private businesses (which I don't believe they're planning to), I wouldn't use any business that uses this service.

I apologize if this sounds futile or like I'm donning my tinfoil hat, but my guard is way up these days.


I would use this if it was implemented as a federated state-level service, expanding on drivers license/ID card programs. Not everything, but certainly for applications that already require a drivers license (eg airlines, banks, apartment applications).


The Danish NemID ("easy ID") uses the Danish SSN, a password and strike list for login to the many government services (you can get divorced online if both parties agree ), banks, contracts (e.g. signing deeds to a house), gambling where you need proof of age or other proofs of identity (e.g. you can validate yourself on the eBay/craigslist equivalent to make your buying/selling more credible).

NemID itself is ran by a private party -- the basic pricing is 50 cents per unique user or 15 cents per session if you are a non-government entity.

There are some privacy protections -- as non-government entity you cannot get to the SSN, just another ID, but you can ask the user to enter their SSN and verify it's valid for that user.

It's working pretty well after they finally got rid of the Java encryption applets. However you need to have a Danish SSN to use it, so you either live in DK or are a citizen.


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


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.


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.


I like the other commenter's remarks about warrants.

> are you more scared about data security in an online identity provider provided by the government or Facebook et. al.?

Fair question. I'd still choose Facebook, mostly because they have an economic incentive not to screw it up. The government, on the other hand, has no such incentives. I mean, I trust both about as far as I can throw them, but at least one stays in business by practicing good security.


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.


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.


What you have to realize is that the US government is full of life long bureaucrats who are not democratically elected and are in no way held accountable like the representatives. And the representatives are perfectly happy to throw their hands up and hold hearings every time the bureaucrats do something wrong without actually taking the effort to change anything. To me, this is no different than Facebook and Google.


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

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.


Can you elaborate on what you were hoping for?


Restricting access to the password hashes using database security so that a vulnerability in the web application cannot expose password hashes unless a separate vulnerability in the database was also exploited. In PostgreSQL (and other SQL databases), this generally involves having multiple database users with separate permissions, making it so that the database user the web application uses doesn't not have SELECT permissions for the password hash column.

If you want an example for a Ruby authentication library that does this, there is Rodauth: https://github.com/jeremyevans/rodauth


Or maybe they have stronger access controls within their production environment and we don't see that specific configuration in the code?


That could be the case, but if you are going to open source the application, what would be the point of trying to hide it?

Considering that password hashes are stored in the users table, it seems unlikely. While you can use PostgreSQL to implement per-column permissions, it's a fairly large pain, and you have to make sure every query you are using that selects from the table does not select that column. Rails/ActiveRecord by default selects all columns in the model's table, and it's a fair amount of work to work around that.


what is database-based security?


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.


Based upon the various negative findings by the GSA IG's office I don't expect much from 18F. If you can't be bothered to comply with required government IT security requirements why should I trust you to comply with the ones you have made up for yourself.


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


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/ (and each project links to the right repos if you want to see the code/docs)

*I work for 18F


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 :)


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.


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


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

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

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


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.


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.


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.


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?


the US adopted a system that was good enough at the time, and since then there is little impetus for improvement, despite the now obvious flaws. Same story for US infrastructure. Disadvantage of being a first mover


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.


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


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.


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

Should they have used an EV certificate?


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


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


They can be taken over.


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


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.


Wait, but this is for accessing data that the government already has about you. So while sure they could impersonate you, the NSA/FBI/whomever could also just access the government database that stores the information.

The only way to fix this is with something like per-user encryption of data, in which case a master password wouldn't help, although I'm not quite sure how you'd implement oauth and have an encryption password. Maybe the oauth system uses your password to decrypt a personal encryption key, and that is then sent to the client services. That way a master password doesn't get access.


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


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


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.


Is it even possible to use this for a private business? The title literally says that it is "to simplify access to public services"


I sure hope it will be restricted to public services... I was reacting to other comments on HN


According to the developer registration instructions (https://developers.login.gov/register/) you need to provide what government agency you are registering for. Therefore I don't believe this is open to non-government agencies.


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


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.



I wouldn't call Manage Account "teeny and hard-to-notice". I spotted it immediatelly as I'm used to look up in the right corner for logging in on for example reddit.


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.


Its important to remember that login.gov isn't an account its an Identity Provider. It will allow you to prove to an agency that you are who you say you are, but all the account information will be stored by the agency.


Will it? Apparently login.gov doesn't even ask for your real name?


Sure, but other services using it will. And the login.gov account will be a handy new primary key for relating disparate databases across government resources.


you know what I like about google+ if someone miss uses it I don't really care. I don't use it for anything Important.


> Its important to remember that login.gov isn't an account its an Identity Provider.

Doesn't matter, the consequenes are the same. If it is compromised or exploited (internally or externally) the exploiter can access all of your information from, and impersonate you too, all the government systems that rely on it for identity.


I don't think that was the concern being expressed by the grandparent. If the concern was the government now has a secret trove of all your information this specific product doesn't change anything on that front as it doesn't store your information it just acts as an identity provider. If the concern is exploiting this one account allow an attacker to get at all your government systems, then yes this is a new treasure trove. I am going to fall on the side of its better to have one secure account then 100 different less secure accounts. I think the industry has found this to be the case and widespread use of Password Managers and Oauth based logins backs me up on that.


I'm not saying that it's not better net, I’m saying that, insofar as there is an internal or external risk of compromise or abuse, a single government identity provider poses the same kind of risk as a single government profile would provide.


I pity the fool who hacks such a strategic government service. The expression "threw away the key" comes to mind for what might happen to them.


Improper (but not necessarily unsupported from above) internal use is at least as worrisome as hacking, and centralization reduced the size of the necessary conspiracy and the probability of detection and whistleblowing.)


I don't get why you downvoted. One phishing on your healthcare plan and you loose access to your taxes.


It's hard to say that our government really protects our privacy by scattering copies of our information across a constellation of bureaucracies. And protect from who? Who's really more dangerous than our government itself?

login.gov is obviously a good idea. Can you imagine how awful government website's internal authentication software must be? This is like Auth0 for government agencies. It will probably be 10x worse than Auth0 but 10x better than the atrocities probably being committed right now.


Obviously it's not going to get hacked or anything...I mean once an organization gets so big it's vastly better at keeping it from getting hacked...


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.


> 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

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.


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


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

Yes they do. Spotify is asking Google, "Hey, does this web browser have the ability to log in to Spotify as this fellow?" Google can say yes whenever they want, and Spotify is completely trusting the answer.

Google is supposed to only say yes when it's your browser, and not when it's a Google employee's browser, but you have absolutely no way of knowing that.

When you use a third-party site for authentication, the security properties are exactly the same as if you had generated a new random password, wrote it down, and gave it to the third party.


Yes but anyone who pops your Google+ account can get all your playlists.


In the case of Google, you can trust their security over the (usually) much smaller vendor. With this? Not so much.


I, uh, skimmed it. But bear in mind, once your data is already handily collated by a common system/identifier, it's one policy change from being able to automatically connect that information and make it available.


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

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


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... -- which has a limited lifetime battery; I don't check my account often enough so I'm not bothered with the paper card.


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.


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.


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


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


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


France has something similar called franceconnect: https://franceconnect.gouv.fr


Login Spec Here: https://github.com/18F/identity-idp/blob/master/docs/encrypt...

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?


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


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.


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


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.


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


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

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


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


Possibly silly question but how can you be sure the code on github is the same code running on the site. Not trolling, just curious.


This is a US Digital Service project for 18F. Probably the best engineers in the world working on it.


Hmm...you have to move to Washington DC to work for them, they won't pay for relocation, salaries are capped by federal pay grades and are lower than a tech company in SF or Seattle would pay, no bonuses (or stock options, obviously).

I'm sure they have some bright (and altruistic) employees, but I'm not sure the best engineers in the world would work there when they can earn far more compensation at a tech company.


Many people want to make software for the public good via the public sector. For some, the opportunity to do that outweighs the benefits of earning top-of-the-line paychecks.

It seems deeply cynical to correlate geographic areas with salaries and infer that the best engineers in the world will be drawn there, bar none. There are other incentives. Some might even say that engineering of this sort is better executed, or more trustworthy, when performed by people with civic motivations rather than mercenary ones.


You need to move to DC to work for USDS (https://www.usds.gov/join#relocation), but you can work for 18F from anywhere in the US (https://18f.gsa.gov/join/). The login.gov team includes both USDS and 18F team members (as the blog post says).

Also the salary cap is $161,900, as shown in this pay grade table for SF: https://www.opm.gov/policy-data-oversight/pay-leave/salaries... Not a top-of-the-line private sector salary, but not some kind of hardship.


160k is a run of the mill senior engineer salary.... The best engineers in the world can earn 300k or more in Silicon Valley. It takes an altruistic engineer to give up half his salary to work for the public.


Arguable, and they are still working within/for the government. I have little to no faith.


Old reputations are hard to shake. This speech[1], by the first administrator of USDS, is my favorite to quote on the topic:

> Some of you, not all of you, are working right now on another app for people to share pictures of food or a social network for dogs. I am here to tell you that your country has a better use for your talents. [...]

> The Social Security Administration mails checks from a mainframe running COBOL, which might kind of be OK except that more than half of the workforce that maintains it is at or near retirement age. What happens then? The Department of Veterans Affairs has a serious backlog of disability claims. The U.S. Citizenship and Immigration Service processes permanent resident applications and everything else on paper. If you lose your green card, it will take you 6–8 months to get a new one and in the meantime you will not be able to prove you have the right to be in the country or get a job.

> All of these are design and information processing problems and all of these are matters of life or death to millions of citizens and all of them are things you can fix if you choose to.

Think about the response to the hurricane this weekend - that's a government function, and we need talented people serving to make sure that people who lose their homes retain access to shelter.

[1]: https://medium.com/the-u-s-digital-service/mikey-dickerson-t...


Fine.

The only person I know who works for USDS is one of the most talented engineers I've ever met. He's a foreign national but was recently naturalized.

He made boatloads of money off of stock options and loves the idea of solving these kinds of problems.

He owns a house in a western state but maintains an apartment in DC and jokes that he "loses money" by working for the government.

I'm sure not everybody's like him, but come on, give USDS a chance.


nice. SSO for govt. why not?


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


The Government equivalent of Equifax. YAY!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: