81–90 of 173 posts
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 passw…
Earlier quoted context omitted.
This is a US Digital Service project for 18F. Probably the best engineers in the world working on it.
Arguable, and they are still working within/for the government. I have little to no faith.
> 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...
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 passw…
Can you elaborate on what you were hoping for?
If you want an example for a Ruby authentication library that does this, there is Rodauth: https://github.com/jeremyevans/rodauth
Earlier quoted context omitted.
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.)
I'm pretty certain they can already do that though.
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 passw…
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…
Earlier quoted context omitted.
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?
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?
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.
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.
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.
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
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 passw…
Or maybe they have stronger access controls within their production environment and we don't see that specific configuration in the code?
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.