Not very reassuring that when you reset your password they send you a new one in plaintext over email....
Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
121–130 of 194 posts
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#122Earlier 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.
Gmail [0] ignores dots in your email handle and so you could use a different pattern of dots for each website you register at and record it in a spreadsheet or something. The first and last characters cannot be dots, and I do not think you can have two or more dots in a row, but there is no limit to how many "legal" dots you can use. Not as elegant, but definitely doable.
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#123Is there a database of subtitles besides Opensubtitles that we can use as a fallback? It would be great if there was a Github repo with a updated lists of .SRT files we can download at our leisure.
Only caveats:
- Github wouldn't like millions flocking to a repo to grab files.
- I'm not sure sharing of subtitles fall under 'copyright violations'. It's a bit of a grey area. (it's just text right?!)
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#124Which is why I use password manager, with one unique & strong password per site. Risk management is important as there is no way to know what website has any known or unknown security holes in it. (Especially those built years ago) When possible use password manager with End to End Encryption (E2EE). Maybe Independent Security Audit too.
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…
For me the main thing that stops me from using is poor support for non-website passwords, which you already mentioned. I also miss having a "notes" field where I can write down what email I used to sign up, or answers to security questions (I like having "fake" answers for those).
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#125Reading this makes me furious, not because they were hacked but because this shitshow of a Website was so damn lazy. (paraphrasing) "We were stupid 15 years ago and have been lazy ever since" is a slap to the face. Maybe they should have done something about their platform instead of watching anime with subtitles. Those people should have their internet privileges permanently removed and the whole site should be burn…
Adding insult to injury is the last Paragraph I actually missed:
> If companies like microsoft, facebook, twitter, nintendo or zoom can get hacked, what are our chances as a tiny team to not endup getting attacked ?
It's not about them getting attacked but they weren't the target of a three letter agency Throwing weaponized 0days their way either.
Anything that is remotely considered best practice would have helped:
Like having strong passwords for the "SuperAdmin" account that was compromised. It's called SuperAdmin for a reason don't you think?
Not using unsalted hashes in the first place?
Investing some of your ad revenue in making security updates to a system that was already bad the second it was conceived?
Their whole statement is insulting
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#126Tangentially related to this: Is storing passwords actually hard, or is it knowing know to do things like this that is? I've seen a lot of people on HN talk about how they never store passwords because they don't want the liability, and I've seen some talk about how they do since it's simple. In my experience, hashing with Argon2 and keeping that in the DB (for toy personal projects) has been very easy, especially to…
Mostly A. Why bother with ever getting a password and having to deal with it in any way, versus delegating that aspect of security to a FAANG-level company with a > $1m security budget?
You can store your password yourself, sure, but how certain are you that you're doing it "right" and that "right" today will be good enough tomorrow? 15 years ago MD5 wasn't perfect, but it was good enough versus the other common/stupid methods of storing the password directly or storing it encrypted vs hashed. How certain are you that Argon2 is going to stand the test of time for another couple decades?
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#127Is there a database of subtitles besides Opensubtitles that we can use as a fallback? It would be great if there was a Github repo with a updated lists of .SRT files we can download at our leisure. Only caveats: - Github wouldn't like millions flocking to a repo to grab files. - I'm not sure sharing of subtitles fall under 'copyright violations'. It's a bit of a grey area. (it's just text right?!)
> (it's just text right?!)
So are books unfortunately.
I would really love if there was an open subtitle repo though. Hell I'd even help make it myself but xkcd/927 and whatnot.
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#128Earlier quoted context omitted.
> The reality is likely to be: they make a very small amount from ads and user donations that might, if they're lucky, cover the costs of hosting Opensubtitles has a VIP program at $15 a year. It's quite easy to find the person who runs the site and, according to their CV, this is basically their job. That'd make Opensubtitles a for-profit piracy site, i guess.
Subtitles aren't piracy in any way though. Kind of similar to legality of torrent sites but even less questionable.
It takes hours of work to translate one hour of movie, so when a translated subtitle is copied, it is most certainly piracy. If you are faster than that please consider becoming a translator for sites like the TED foundation.
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#129Earlier quoted context omitted.
> simply do bcrypt(md5(password)) This could also be problematic. Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ
Honestly, not as a big a deal as some people make it. First off, you'd have to assume the attacker knows the bcrypt hashes are bcrypt(md5(password)) – an attacker wouldn't always know this Also it assumes there is password reuse, but that the password is strong enough that the md5 is uncracked.
I'm also not quite sure about the circumstances where that would be relevant, but on the StackExchange a sibling comment found there is this further explanation:
> > I know I'm probably stupid but... how is this different from a dictionary attack? Instead of trying a list of known passwords, you try their md5s. If the md5 hasn't been cracked before, chances are that the password is strong enough to resist being cracked now. – nobody Jul 17 '20 at 14:55
> Because there are plenty of MD5s in the wild that A) just happen to not have been cracked yet because they weren't interesting enough to stand out, but B) once an attacker can figure out that that MD5 is inside a really interesting, high-value-target bcrypt, they might spend a lot more effort to crack that MD5. So it's not just a dictionary attack; it's a dictionary attack of passwords that are currently unknown but might be crackable with additional effort. And that effort is much less than trying to crack that password if it was only inside a pure bcrypt. – Royce Williams Jul 17 '20 at 15:00
https://security.stackexchange.com/questions/234794/is-bcryp...
So the assumption is: There is a breach A of an low-interest target with MD5 hashes and a breach B of a high-interest target with BCrypt(MD5) hashes. As A is not interesting enough, people don't invest the time to crack A's MD5s. But as B is super interesting they will use A as a dictionary source to then know on which MD5s they should invest a high amount of time, as it will help them crack the high-interest target B. Note that no specific user association takes place, like in the presentation about password shucking by Sam Croley (above Youtube link), where usernames/emails of A and B are correlated.
I think this is a bit more plausible than Croley's take on it. Because if I have identified a high interest individual, I would already invest a lot time to crack the MD5 password.
And yes, what you said bears repeating: All of this attack lives in the small space where the password is too strong to be cracked from a simple MD5 hash when you are mildly interested but not strong enough to prevent cracking when you are deeply interested – for varying degrees of mildly and deeply interested. Overall I would like to read about real world examples where this made the difference and how that password happened to fall into that region.
Re: Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
#130A 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.
Great idea, but seeing as you are rearchitecting you might as well add the salt to the MD5 while you are at it.