Hacker News Reader

Comment by shuntress | Hacker News Reader

The problem is deeper and simpler than that.

Authentication should not need to be re-implemented by every single organization. We should have official auth servers so that FlyCASS doesn't need to worry about identity management and can instead just hand that off to id.texas.gov (or whatever state they operate from) the same way most single-use tool websites use Google's login.

View on HN

Authentication and authorization, and especially on the web, is one of those things that has never been implemented well. I hate every single piece of software, every standard, every library, every approach I have come into contact with from this domain. I am so glad I have nothing to do with this field anymore. It makes me angry even thinking about it.

Be the change you want to see in the world.

I agree with that sentiment, and I have tried to contribute in the past, but then again, you have to choose your battles. Making the kind of impact on auth that means I, or anyone else, will not have to deal with rubbish systems in the future is a big task.

It is one thing to write the needed software, it is a much bigger task to convince enough companies that they need a different approach to this problem.

However, what I can offer is that if someone has the backing to actually make a difference in this market, I'll volunteer 50 hours to act as a reviewer and test developer. But that is if your project is backed by someone I believe can make a difference.

This exists in some European countries, in Hungary for example you have an identity service (KAU) which authenticates you and operates as an SSO provider across a number of different government properties.

The United States has it, too: https://login.gov

But with a government as large as America's it's going to take time to get everyone converted to the new system.

FWIW, as a regular user of login.gov, from the outside, it looks like a well-designed system. I am able to add strong forms of 2FA (e.g., security keys or biometric authenticators), it requires strong passwords, etc. It also has decent developer documentation, has a support process, and comes with a vulnerability disclosure form baked into the main website. However, I have not used their API, nor have I seen any of the code (although I wonder if a FOIA request would actually compel them to give it to you).

> although I wonder if a FOIA request would actually compel them to give it to you

I believe most of it is open source: https://github.com/18F/identity-idp

Americans as a whole are so allergic to government doing anything that we can't even get a national ID system nor a centralized database of gun sales or ownership. The bogeyman of evil Big Government, privacy, and censorship gets invoked. It's fine if the Free Market does it, so Google, Facebook, Amazon, Twitter, Microsoft, et al get a free pass.

The "free" market, i.e., government-funded market.

The first bullet point on the /partners page of login.gov (regarding who should use it) says:

> You are part of a federal agency or a state, local, or territory government

I'm talking about a more generic service that any random industry system or individual can use. The way many websites use Google's OAuth without using really using Google's APIs. Things that just want someone else (Google) to handle asking for and authenticating a name/password.

Not 100% sure how I feel about random companies being able to definitively identify me. I’m sure we’re drifting in that direction anyway, but it feels like it would negatively impact privacy online.

> Not 100% sure how I feel about random companies being able to definitively identify me.

But that is not what we are talking about. It is not that you are browsing the web randomly and some random company identifies you as d1sxeyes.

It is that you can identify yourself towards any company if you choose to. Then you can decide if that is in your best interest or not.

It also is not necessarily your actual ID. As far as the individual website needs to know, it could just be a random string of numbers and letters. As long as it's the same string each time they ask the authentication authority to confirm you.

> single-use tool websites use Google's login

Topic drift, but no tools should use google login. Doing that means handing over to google the authority to decide who can and can't use your tool. And we all know google support is nonexistent and unreachable, so once it fails it's forever.

If you market a tool, you'd really want to own the decision on who you can sell it to.

For a government organization though, I'd agree it makes sense to use a government-run login service. (government run, not outsourced so some for-profit third party!)

Trusting Google's OAuth not to vanish overnight is less stressful than managing your own username/password database.

And that's pretty much my point. 2FA? Password Resets? Account Activation? Updating Email Address? No thanks. I would rather not have to deal with any of that. I literally just need a unique identifier to associate with your data and preferences.

Many well-established web frameworks have plugins or components to handle user management out of the box, with sane defaults. Nobody should have to roll them by themselves with each hobby project. You're probably using a similar plugin to integrate with Google anyway.

> Trusting Google's OAuth not to vanish overnight

Sorry if I wasn't clear. It is not that google will remove the service overnight (although they are infamous for canceling things, but not that bad). The problem is google will lock out users randomly for no reason and no recourse.

If that user was using google login to access your service/tool, you lost that user and there is nothing you can do. You really don't want to gate the access to your product via an unreachable unresponsive third party like google.

This seems like exactly the sort of work the US Digital Service should take on.

Would still need an audit to make sure sites are actually using the shared auth and not rolling their own.

I'm not saying anyone should be disallowed to run their own authentication.

I'm saying we need the digital equivalent of "show me your driver's license".

I think that is the goal of https://id.me

Would that be https://id.me ?

It's what the IRS uses.

That's of course the stupidest possible domain for a government website. (Or at least it's up there)

Fundamentally, it has given control over the DNS records to a different country (.me == Montenegro).

It's training people that really, any domain could be a government domain, you'll never know.

It's also not a government web site. It's a private company who, for some reason, my own government outsources identity verification to. Meanwhile, the authorization system the US government has built (login.gov) is deemed "insecure" by the IRS and Social Security for some inexplicable reason. (But it's fine for Trusted Traveler Programs.)

Social Security has implemented Login.gov integration. IRS returned detailed feedback that GSA is working on.

This is good news. Thanks for sharing.

> It's a private company who, for some reason, my own government outsources identity verification to

Welcome to the neoliberal wet dream.

Because it's not a government website, it's a company the government contracts with.

Yes. I know how this works. This doesn't change that's it's stupid. You can't outsource stupid and then claim it's not your problem.

Yes, welcome to the rest of the world.

You're aware that there's a registry per country, no? And that that each country can choose to set aside a subdomain for all government services?

Yes, it's unfair that the US gets naked .gov - but that doesn't preclude the rest of the world from doing the right thing, and it certainly doesn't excuse the US government doing the stupid thing.

The US government can still basically yoink any ccTLD very very easily. It won't, but it could.

It's not a government website.

It's the company providing the service that the government could provide on its own, but that service is being provided by a private company through a lucrative contract agreement.

Apparently Venmo also has a option to look up an image of any person, we could use that too.

I think they (quietly) turned that off after a researcher exposed it earlier this week.

And what a steaming pile of dogshit it was when I registered:

"Scan the front and back of your Driver's License."

[upload scan of front of DL @ 200DPI]

"Unable to find a face in the image you uploaded."

[upload scan of front of DL @ 300DPI]

"Unable to find a face in the image you uploaded."

Huh. Maybe I'll try with a lower resolution.

[upload scan of front of DL @ 72DPI]

"Thank you, now please upload the back of your Driver's License."

Hmm, 72DPI worked for the front, so...

[upload scan of back of DL @ 72DPI]

"Unable to read a barcode in the image you uploaded."

[upload scan of back of DL @ 200DPI]

"Unable to read a barcode in the image you uploaded."

[upload scan of back of DL @ 300DPI]

"Thank you for verifying your Driver's License".

Ah, but there are third-party services that provide identity verification, such as id.me. And now that there are for-profit entities involved in a government service, you will never be able to convince the government to implement their own solution. It's telling that id.me is headquartered in McLean, Virginia; gotta be in the DC metro area so your lobbyists have easy access to Congress.

I want you to be wrong, but you probably aren't.

Reply on news.ycombinator.com