Live data from Hacker News

Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

forum.opensubtitles.org

91–100 of 194 posts

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#91

Earlier quoted context omitted.

> to prevent super long passwords from eating up CPU time Is that why websites sometimes have low maximum password length requirements ? Ex: must be less than 20 characters.

Super long is >100 character passwords. Not much point: either the hash function is broken or some other hack will happen before humanity develops enough compute power to crack 100 char bcrypt passwords. Websites (like some banks used to) that have less-than 20 char limits for passwords are purely bad security strategy.

The number of sites that restrict passwords to 20 characters drives me nuts!

There needs to be a limit, yes, but surely something like 100 characters, or even 50, would be more sensible.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#93
post #58

A tip I learned recently: if you see a database with a simple hash with no salt(md5, sha256…) like this, and you want to migrate to a secure password hashing function (bcrypt, argon2…) you don't need to wait for the users to re-login: simply do bcrypt(md5(password)) immediately, and delete the old hashes, and you get higher security.

Slightly related, in order to prevent super long passwords from eating up CPU time is it better to hash using sha256 before argon/bcrypt so that the length is constant, or is it better to limit password length to some arbitrary number like 64 characters

I've been tempted a few times to simply use salt and a single iteration SHA-256 to store passwords, and put something like this on the account creation and password change screens:

> If you care about the security of your account use a 20+ character random password and do not reuse that password at any other sites. There are several excellent password managers that can generate and remember such a password for you and make it easy to use. Here's a list: .

> We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and . Set your password generator to length 20+ and to use mixed case, digits, and symbols and you will be fine.

> If you think you might have to manually type this password at some point, you can use a reduced character set with a longer password. If you use just mixed case letters and digits make the password 22+ characters long. If you use just mixed case letters make it 23+ characters. Letters all of the same case? Make it 28+ characters. 32+ characters of hex is fine, too. Heck, you can make it all digits if you use at least 39 of them.

> If your password manager offers other options, such as patterns like groups of digits or pronounceable syllables separated by some symbol, that too is fine as long as you make it long enough. Make it long enough that your password manager gives it its highest strength rating.

> The exact upper limit on password length that our password entry fields allow might vary from time to time as we update the site, but will always be at least 64 characters.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#94
post #58

A tip I learned recently: if you see a database with a simple hash with no salt(md5, sha256…) like this, and you want to migrate to a secure password hashing function (bcrypt, argon2…) you don't need to wait for the users to re-login: simply do bcrypt(md5(password)) immediately, and delete the old hashes, and you get higher security.

Slightly related, in order to prevent super long passwords from eating up CPU time is it better to hash using sha256 before argon/bcrypt so that the length is constant, or is it better to limit password length to some arbitrary number like 64 characters

What's wrong with super long passwords eating up CPU time? Can't imagine it is that prevalent with normal users and there are other ways to deal with it if it is a vector for a DOS attack (rate-limiting the number of registrations or logins, for example).

NIST says there's no reason to limit password length any more[0]:

"Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets."

0: https://pages.nist.gov/800-63-3/sp800-63b.html

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#95
post #49

Earlier quoted context omitted.

But both you & GGP are talking about bcrypt as though it was only a password hash. If someone says, "I'm using bcrypt", then they are using both a password hash and unique per-password salts, or they're not using bcrypt. What makes bcrypt and other such systems nice (and makes this kind of mistake basically inexcusable in 2022) is that if you're using a library or package which implements it (which you should), you d…

I mean, sure, but, notice that you're still way behind state of the art for the end of the 20th century. I blame Tim (Berners-Lee, the man whose toy hypermedia system we're all stuck with because it became popular) You note that when you googled "Password hash" you got pointed to a decent password hash. But, knowing what questions to ask is half the battle. Too many people figured hey, I should use a cryptographic ha…

> with readily available devices (e.g. my phone) and yet

I'm pretty sure it wasn't anywhere near ready to use five years ago when I wrote v1 of my webapp. And googling again, it's still not clear whether it would work on whatever random software setup some of my zealous-for-software-freedom colleagues use. With passwords I don't need to worry: if they can render the HTML+CSS (even the JS is optional, because some of my colleagues prefer NoScript), they can log in.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#96
Meh. I treated that site like every random site that requires a login that I think I'll use once: it got my 20 year old Hotmail address, a randomly generated password, and was accessed solely from my VPN IP.

The only reason I even set up an account was so that one of my Kodi extensions could hook into it.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#97
post #58

A tip I learned recently: if you see a database with a simple hash with no salt(md5, sha256…) like this, and you want to migrate to a secure password hashing function (bcrypt, argon2…) you don't need to wait for the users to re-login: simply do bcrypt(md5(password)) immediately, and delete the old hashes, and you get higher security.

> simply do bcrypt(md5(password)) This could also be problematic. Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ

Thanks for sharing this, TIL.

It's a very interesting attack, highly specific to the high-number of breaches, high password reuse environment we're in that enables at-scale password cracking.

I don't think it invalidates this advice completely. You should watch the talk and eventually add a global pepper (assuming it does not leak), and of course do the final bcrypt(md5(pass)) -> bcrypt(pass) migration upon user login.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#98

Meh. I treated that site like every random site that requires a login that I think I'll use once: it got my 20 year old Hotmail address, a randomly generated password, and was accessed solely from my VPN IP. The only reason I even set up an account was so that one of my Kodi extensions could hook into it.

I used it like a public site, using a very popular password. Same as in other sites where people share the same account between multiple people.

I don't really mind that they got breached. I hope they recover easily and continue to offer their service.

And I will not change that password, unless I am denied access. Don't really care if people know it.

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#99

> user passwords are saved in safe form using hash_hmac and sha256 algo with salt and pepper, all md5() passwords are deleted Wait, what? Definitely lesson not learned: - sha256 is not the proper way to store passwords, it's still vulnerable to the same attack as md5, rainbow tables, because it's a FAST algorithm (sure md5 is also poor for collisions, meaning it's worse, but practical attacks for lists of hashed pass…

Or how about "we moved to an open source library or third party auth provider to host all our user data. We learned we didn't want to be responsible for such a critical security area."

There are lots and lots of options. Seems like they are a php shop, so even moving to any of these open source PHP server libraries[0] would have been a better move.

Disclosure: I work for a third party auth provider, FusionAuth.

0: https://oauth.net/code/php/

Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames

#100

Earlier quoted context omitted.

I think you massively underestimate how much ads can bring in with a high traffic website: https://www.similarweb.com/website/opensubtitles.org/ I'd guess about $1-3M/year from ads.

You are overestimating how much ad revenue comes in from non Tier 1 countries and from that specific niche. I'd be surprised if they get more than $1-2 per 1000 visitors. Could be lower than that

$1 / 1000 visitor is $110k / month with 11 million visitors which agrees with my estimation.
Post reply on HN