Live data from Hacker News

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

forum.opensubtitles.org

81–90 of 194 posts

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

#81
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

> Many implementations of bcrypt truncate the password to the first 72 bytes, following the OpenBSD implementation.

https://en.m.wikipedia.org/wiki/Bcrypt

This sounds undesirable to me, so I'd support sha256 and an alternative.

I'd also recommend adding a max password length to any API. No point in allowing million character passwords.

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

#82

Earlier quoted context omitted.

So, still a wrong procedure. They should have told everyone to renew their password and view them as compromised in August. Edit: typo

> nothing was leaked in august, we followed the hackers request, secured our services, hired an extra sysadmin, ran extra audits. Oh yes, what could ever go wrong with keeping already compromised passwords? Plus it was clearly a white hacker that helped them secure the website, the required fee was for this service. /s

It's truly appalling that so many times, on HN even, people genuinely recommend paying the ransom because "hackers won't go back on their word cause it'll ruin their reputation". If you're hacked, purge the passwords and reset everyone and do everything in your power to ensure no one can access it in a similar way again. I have no idea why anyone would think a hacker wouldn't simply turn around and sell the data anyway

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

#83
post #59

Earlier quoted context omitted.

I use my own domain and give each website their own e-mail address too, so I know who is breached/selling my information. For password management I use BitWarden, to which I am a paying customer of 15$ a year for their premium features (Premium features being TOTP integrated into the password manager, probably something else too that I don't use). BitWarden is open source, both server and clients. There's even a thir…

> I use my own domain and give each website their own e-mail address too I wish this was a supported feature on @gmail.com domain (not the +{string} thing). I like the idea, but keep thinking that I'll be uniquely identifiable on every database, since it's almost always going to be just 1 entry for the domain I own.

A proprietary Fastmail feature generates anonymous @fastmail.com addresses for you, but I mostly use my own domain since I don't want to be locked in to one provider.

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

#84
> The site was created in 2006 with little knowledge of security, so passwords were stored in md5() hashes without salt Sorry, but this is no excuse. It has been 15 years and there were so many breaches that even many casual people know about databases leaks and that passwords have to be stored in some special way. I don't know this guy's background, but he at least knows that md5 is not sufficient here. And then it never crossed his mind to do a check up on this? That's just negligent.

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

#85
post #71

Earlier quoted context omitted.

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 think an average user password would be shorter than a sha256 hash no?

Bcrypt truncates to 72 bytes, so it's kind of irrelevant IMO. Whether your average length is 12 or 20 or 64 bytes doesn't matter much.

I expect the parent's concern came from experience with PBKDF2, where the length is unbounded. It's good to consider possible denial of service attacks: if someone submits an enormous 1 MB password a PBKDF2 hasher can be knocked offline for 60s. Sha256 will quickly crunch that attack to a more manageable length.

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

#86
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

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

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

#87

Earlier quoted context omitted.

Can anyone talk me out of the Firefox password manager? It has a poor "general" use case for non-website passwords and treats mobile as a second-class satellite, but it seems to just work and the sync between mobile and desktop is very handy. https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ I read and understood just enough of this when it was published to know it would make the foundation an object of ridicul…

KeepassDX (Android) has a really nifty keyboard feature which allows you to even put passwords in apps, which the regular Firefox Sync doesn't support. Maybe that's the use case which makes you do the switch?

Firefox Android (and iOS it seems?) actually supports autofill for other apps, one just needs to enable it: https://support.mozilla.org/en-US/kb/end-of-support-firefox-...

(I've used it quite successfully when it was in a separate app called Lockwise)

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

#88
post #53

Earlier quoted context omitted.

I think one use case was subtitle downloading (typically, a client like Subdownloader) for VPN users, whose requests would be denied if unauthenticated.

Why? The site's raison d'etre is to make subtitles readily available for downloading by anyone. What is the purpose of locking it behind authentication? What did that realistically achieve?

API REQUESTS MUST BE AUTHENTICATED

With Covid-19 pandemic requests for our API went skyrocket, our servers could not handle so much traffic, so we decided to limit API usage just to authenticated requests for User Agents. In short it means, you have to provide opensubtitles.org username and password in LogIn() method.

We are avare some of user agents doesn't implement authentication for numerous reasons.

What you can do for fix, if your app is affected: - let your users know about this change - implement LogIn() into your app with user authentication - contact us for pricing, so your app can send unathenticated requests (e.g. if you have free and pro version of your app, it is possible free will work only with authenticated requests and pro works as before)

More info on [our forum](https://forum.opensubtitles.org/viewtopic.php?f=11&t=17110)

We are actively blocking IPs, which are sending unathenticated requests

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

#89

Earlier quoted context omitted.

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

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

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

#90

Earlier quoted context omitted.

> nothing was leaked in august, we followed the hackers request, secured our services, hired an extra sysadmin, ran extra audits. Oh yes, what could ever go wrong with keeping already compromised passwords? Plus it was clearly a white hacker that helped them secure the website, the required fee was for this service. /s

It's truly appalling that so many times, on HN even, people genuinely recommend paying the ransom because "hackers won't go back on their word cause it'll ruin their reputation". If you're hacked, purge the passwords and reset everyone and do everything in your power to ensure no one can access it in a similar way again. I have no idea why anyone would think a hacker wouldn't simply turn around and sell the data anyw…

I think people recommend that in case of ransomware, which is most of the time the only chance of getting the data back (helping the ransonware market thrive, and with the risk of not getting data back anyway).

Never saw anyone suggest paying for avoiding password leaks

Post reply on HN