Government launches login.gov to simplify access to public services

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

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!

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

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.

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.

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.

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

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

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

  load_testing_mode: true
  send_email: false
  telephony: false

  if !disable_email_sending
     do_send_email

  if send_email
    do_send_email

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.

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.

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?

Should they have used an EV certificate?

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.

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.

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

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

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

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?

It seems very big brother-ish to me.

I don't buy it.