101–110 of 113 posts
For a long time, environment variables have been evangelized as the secure place to store credentials and things, but that just gives third party scripts a known place to look.
You could argue that might actually be more secure to store your secrets in a separate, custom config file that gets read into the rails app via an initializer or something.
Earlier quoted context omitted.
Yeah I'm assuming the methodology is: 1) Find high-value target libraries 2) Grab the usernames of accounts with push access 3) Check those against password dumps I feel really stupid about this, but like I said it was an oversight. I apologize and will try to do better.
Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!
Ruby gem hijacking also happened to Strong_password a few weeks ago. https://news.ycombinator.com/item?id=20377136 This is major new line of attack, and web app infrastructure is critically weak to it. We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons), but as this sort of attack becomes much more common (which it will), we might find ourselves missing the da…
> We rejected distro-controlled package management in favor of pip and gem and npm years ago (for good reasons) While I'm generally a fan of distribution-provided packages, they would not have helped in this case. Distributions simply lack the manpower to audit all upstream releases for these kinds of issues.
Earlier quoted context omitted.
That's not very practical if salted hashes are being stored.
but the salt is in the database. You can hash all the known-compromised passwords with the salt and see if any match.
The only time you would have access is when the user logs in, so for rarely logged in users you would have to proactively reset their password or cross your fingers.
Earlier quoted context omitted.
Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!
If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time. The best approach is probably to disable the account completely until an interactive login is made and a pass…
Sometimes you have to have your priorities straight. If you found the password, someone else can find it.
Earlier quoted context omitted.
Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!
If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time. The best approach is probably to disable the account completely until an interactive login is made and a pass…
Earlier quoted context omitted.
Sounds like rubygems and other registries like npm should try to get ahold of those password dumps and check them against their own account databases somewhat frequently!
If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time. The best approach is probably to disable the account completely until an interactive login is made and a pass…
Earlier quoted context omitted.
but the salt is in the database. You can hash all the known-compromised passwords with the salt and see if any match.
The salts should be different for each user, specifically to deter brute forcing of this nature. The only time you would have access is when the user logs in, so for rarely logged in users you would have to proactively reset their password or cross your fingers.
But even with 12 round bcrypt hashing, you should be able to fairly cheaply attack a list of 2,000 bcrypted passwords with a million-entry database of leaked e-mail/password combos in a GPU-month.
Probably easier to force a password reset on everyone and then do the checking on password change, although you need to be careful there not to be sending the password.
EDIT: uhm, wait, so if you've got the e-mail address in the dump then there's only one user for that, so just grab their salt and hash the password and check it. So that million entry database should be checkable in a bit over half an hour...
Earlier quoted context omitted.
The salts should be different for each user, specifically to deter brute forcing of this nature. The only time you would have access is when the user logs in, so for rarely logged in users you would have to proactively reset their password or cross your fingers.
Hopefully you don't transmit the password and are doing challenge/response so that you don't even have it when the user logs in. But even with 12 round bcrypt hashing, you should be able to fairly cheaply attack a list of 2,000 bcrypted passwords with a million-entry database of leaked e-mail/password combos in a GPU-month. Probably easier to force a password reset on everyone and then do the checking on password cha…
Wasn't challenge/response / SRP authentication debunked ?
https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...