Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames(forum.opensubtitles.org)
forum.opensubtitles.org
Opensubtitles.org breached – Email addresses, IP addresses, Passwords, Usernames
https://forum.opensubtitles.org/viewtopic.php?t=17685
193 comments
> Opensubtitles became really frustrating to use once they began asking for a login and a password to download subtitles in VLC or Xbmc/kodi (basically every time you need to use the API).
This was actually optional, and always was. I think the issue was that they had made some changes in the backend, but the addons didn't update the code to accommodate. At least this was the case for Kodi. The opensubtitles addon has essentially become abandonware anyway. There are now third-party addons that provide the same functionality but without a login, and across different subtitle websites.
This was actually optional, and always was. I think the issue was that they had made some changes in the backend, but the addons didn't update the code to accommodate. At least this was the case for Kodi. The opensubtitles addon has essentially become abandonware anyway. There are now third-party addons that provide the same functionality but without a login, and across different subtitle websites.
Can you name a few please?
https://github.com/a4k-openproject/a4kSubtitles
anonymous, scrapes a handful of sites including opensubtitles + subscene
anonymous, scrapes a handful of sites including opensubtitles + subscene
I am confused, the GIF show a login+password for opensubtitles https://camo.githubusercontent.com/a1cd19d17f0484669e61673fa....
Oh, well. I'll give a try next time I launch kodi, thanks for the tip.
Oh, well. I'll give a try next time I launch kodi, thanks for the tip.
It says "Optional" next to the username/password.
Aaaand it's naptime for me :).
The website began to require login within the last three days for me.
I have a heartbreaking story for you about a wildly popular site that allowed people to submit album info from CDs (and then everyone else could have automatic metadata when they ripped their own copies of those CDs)
It became way more frustrating when they started to add ads in the subtitles. It was a few years ago and since then i never even tried to use them
I downloaded the SRT, stripped the ads using SubtitleEdit and embedded them in the MKV file using MKVToolNix to keep it all together.
why bother with any dedicated app just to remove one or two lines of "ad" (99.9% is just them offering ad service, but seems like nobody is interested really), open in notepad, Shift+End, Delete, done
I like to make sure all the numbered lines are all sequential, and I already use it for creating subtitles so why not do it the proper way.
but they will be sequential, you can just fill them with empty space
or you can completely delete whole string including timestamp, it's not like any hardware of software videoplayer cares about missing number
or you can completely delete whole string including timestamp, it's not like any hardware of software videoplayer cares about missing number
huh? I use to download subtitles in VLC through built in VLsub via opensubtitles and nobody ask me for any login/pwd and I download A LOT of subs, sometimes even 5-10 to try with some releases
now on the website I would hit the limit very fast, but through VLsub it's essentially unlimited
now on the website I would hit the limit very fast, but through VLsub it's essentially unlimited
There was a time the built-in VLSub wasn't built-in and I remember at some point it was abandoned and then picked up again. Nowadays it's working again as intended, no more freezes or invalid login. Still has the bug where the next video in a queue picks up the good subtitles but it downloads the subtitle for the previous video.
I googled vlsub opensubtitles not working and I still find relevant threads https://forum.videolan.org/viewtopic.php?t=152485
I have been using opensubtitles since they opened the site though and I couldn't really tell when the problem appeared and disappeared.
I googled vlsub opensubtitles not working and I still find relevant threads https://forum.videolan.org/viewtopic.php?t=152485
I have been using opensubtitles since they opened the site though and I couldn't really tell when the problem appeared and disappeared.
but you present your opinion as if it would be required now, while I use VLsub in VLC FOR YEARS without anyone asking me for long/pwd, so not sure what's your deal but you are clearly trying to mislead other based on maybe many years old experience, while reality for many years is that nobody asks you for login/pwd in VLsub
and yes, it is still sometimes freezing or has issues, but not sure what you expect from service you don't pay anything for, not even in forms of ads if you use it through VLsub
and yes, it is still sometimes freezing or has issues, but not sure what you expect from service you don't pay anything for, not even in forms of ads if you use it through VLsub
Another random thread where someone has a problem with VLC and opensubtitles login password: https://www.reddit.com/r/VLC/comments/aqvzlm/unable_to_work_...
It's from my boy Andrew from the anti-vlsub-opensubtitles cell #3948 in Wichita. Thanks for outing us, we have to rebrand our whole operation now and update banners and usernames, etc. We were so close to convincing everyone to stop using vlsub and opensubtitles :(. /s
> so not sure what's your deal but you are clearly trying to mislead other based on maybe many years old experience, while reality for many years is that nobody asks you for login/pwd in VLsub
It's from my boy Andrew from the anti-vlsub-opensubtitles cell #3948 in Wichita. Thanks for outing us, we have to rebrand our whole operation now and update banners and usernames, etc. We were so close to convincing everyone to stop using vlsub and opensubtitles :(. /s
> so not sure what's your deal but you are clearly trying to mislead other based on maybe many years old experience, while reality for many years is that nobody asks you for login/pwd in VLsub
next time read at least your own 2 years old link, it was caused by him using VPN, if he switched off VPN he didn't need to login anywhere, so no, even two years ago you didn't have to login in vlsub unless you use VPN for some strange reason
> you didn't have to login in vlsub unless you use VPN for some strange reason
So, you don't have to login unless you have to login.
Got it.
Also, this:
https://github.com/exebetche/vlsub#2013-09-05-version-0910
> 2013-09-05 (version 0.9.10)
> Add possibility to set opensubtitles.org username/password in config menu to avoid download limit to unlogged users
You can add this to the list of reasons you needed username/password for vlsub at some point, when you hit their download limit. Which is something that used to happen a lot with fansubs.
So, you don't have to login unless you have to login.
Got it.
Also, this:
https://github.com/exebetche/vlsub#2013-09-05-version-0910
> 2013-09-05 (version 0.9.10)
> Add possibility to set opensubtitles.org username/password in config menu to avoid download limit to unlogged users
You can add this to the list of reasons you needed username/password for vlsub at some point, when you hit their download limit. Which is something that used to happen a lot with fansubs.
And this is why users protect themselves with services like Firefox Relay, something Dustin Ingram, a Python Software Foundation Director, doesn't appear to understand [1] or care. My email was leaked in this breach, along with many others, an email I used to really value but one I've since relegated to the dumpster fire of "spam slot" because I learned my lesson too late.
Dustin has now locked that GitHub to only previous contributors so users are once again left voiceless and powerless in the continuing war against their privacy.
We've been thinking of the business owners and the children [2] for decades now. It's time to start thinking of the users, people like you and me who are exploited constantly for everything they have to be unceremoniously discarded in a waste heap once they've been used up.
[1] https://github.com/disposable-email-domains/disposable-email...
[2] https://news.ycombinator.com/item?id=29978952
Dustin has now locked that GitHub to only previous contributors so users are once again left voiceless and powerless in the continuing war against their privacy.
We've been thinking of the business owners and the children [2] for decades now. It's time to start thinking of the users, people like you and me who are exploited constantly for everything they have to be unceremoniously discarded in a waste heap once they've been used up.
[1] https://github.com/disposable-email-domains/disposable-email...
[2] https://news.ycombinator.com/item?id=29978952
I tried modifying my email to a @mozmail.com on opensubtitles.org after the breach and I never received the confirmation email, so I assume they're blocking it.
Anyway I deleted my account.
Anyway I deleted my account.
Firefox Relay misses some emails due to misconfiguration of TLS. That might be the issue. This issue report is still open:
https://github.com/mozilla/fx-private-relay/issues/757
https://github.com/mozilla/fx-private-relay/issues/757
What nonsense.
1. The repo in question is simply a list of domains. People can choose to block whatever domains they wish. This list holds no inherent harm or ill will and is not a "war against your privacy", it's simply a list of disposable email domains to do with what you wish.
2. This isn't in any way related to security breaches or disposable email domains and appears to be an entirely unrelated topic.
1. The repo in question is simply a list of domains. People can choose to block whatever domains they wish. This list holds no inherent harm or ill will and is not a "war against your privacy", it's simply a list of disposable email domains to do with what you wish.
2. This isn't in any way related to security breaches or disposable email domains and appears to be an entirely unrelated topic.
It's not intended to be just a list of domains. It's intended to be called as a Python library (hence the aforementioned PSF member tending it) by actors who want to prevent user registrations on their platforms by users of disposable email domains.
This much is obvious by spending less than five seconds reading the README plastered on the front of repo. You're also welcome to peruse some of the PRs and issues in the repository if the README wasn't clear enough. In fact, go visit the last comment in the PR I linked: a contributor points to a Hacker News comment for reasoning why operators might want to make use of this blocklist.
I'm sorry, but yes it is related as the operators of repositories like this (and there are others) are deaf to the reasons why users make use of these disposable mail domains. That reason is because breaches like this happen daily and these breaches are a threat both to the public IDs we use for emails and to the private passwords we use, should they be poorly secured.
This much is obvious by spending less than five seconds reading the README plastered on the front of repo. You're also welcome to peruse some of the PRs and issues in the repository if the README wasn't clear enough. In fact, go visit the last comment in the PR I linked: a contributor points to a Hacker News comment for reasoning why operators might want to make use of this blocklist.
I'm sorry, but yes it is related as the operators of repositories like this (and there are others) are deaf to the reasons why users make use of these disposable mail domains. That reason is because breaches like this happen daily and these breaches are a threat both to the public IDs we use for emails and to the private passwords we use, should they be poorly secured.
Interesting. The service I use isn't there lol I'm afraid to tell anyone, now, lest it be put on the list.
The blame belongs solely on opensubtitles.org for using a list to block users and getting hacked. They probably have their reasons but still I feel it is hostile to users that care about privacy.
Firefox Relay is a disposable mail service, so it makes sense to include it in a list of such services. I wonder how they handle mail aliases like GMail allow with + or . as separators.
Firefox Relay is a disposable mail service, so it makes sense to include it in a list of such services. I wonder how they handle mail aliases like GMail allow with + or . as separators.
> 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 passwords are rainbow tables). At least with salt+pepper it limits attack surface, but instead you should be hashing your passwords with:
- `password_hash`[1] should be used instead of `hash_hmac`, with the algorithm being "PASSWORD_BCRYPT" or better[2]. This is a slow hashing method, meaning anyone trying to rainbow-table attack your passwords will have a hard time.
- A common technique is not to delete old passwords, but instead to rehash them with the new algorithm. This would be useful for moving from sha256 => bcrypt, since collisions on sha256 are not practical, but if the original hash was md5 then I think it's fine to delete the md5 passwords and require a new one. Good luck to those who changed their email in 15 years though.
[1] https://www.php.net/manual/en/function.password-hash.php
[2] I haven't followed the space too closely for 3-4 years, I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones
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 passwords are rainbow tables). At least with salt+pepper it limits attack surface, but instead you should be hashing your passwords with:
- `password_hash`[1] should be used instead of `hash_hmac`, with the algorithm being "PASSWORD_BCRYPT" or better[2]. This is a slow hashing method, meaning anyone trying to rainbow-table attack your passwords will have a hard time.
- A common technique is not to delete old passwords, but instead to rehash them with the new algorithm. This would be useful for moving from sha256 => bcrypt, since collisions on sha256 are not practical, but if the original hash was md5 then I think it's fine to delete the md5 passwords and require a new one. Good luck to those who changed their email in 15 years though.
[1] https://www.php.net/manual/en/function.password-hash.php
[2] I haven't followed the space too closely for 3-4 years, I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones
Defense against rainbow tables is obtained via salt, not via slow hashes. A rainbow table is a space-time tradeoff (you give space, and you get time), so using a slow hash only "encourages" (for lack of me knowing a better word) creating rainbow tables.
Adding long salts on the other hand requires the attacker to create an infeasible number of rainbow tables (one for each possible value of the salt).
Adding long salts on the other hand requires the attacker to create an infeasible number of rainbow tables (one for each possible value of the salt).
Technically this class of trades also incurs a lot more hashing (and so the expense of the hash function is important), the trade is valuable because you get to do all the work once, up front, and not spend that time on any particular password hash once you have it.
So e.g. computing a rainbow table for all possible Windows 2000 passwords (up to 14 characters but you're actually only doing 56-bit inputs) in the LANMAN scheme took ages, and produced a fairly large file, but having done so that's it, you, or anyone you give the file to, can reverse LANMAN hashes into working passwords almost instantly.
(Microsoft's LANMAN hash lacked salt, and is stupid in various other ways, MD5 would actually have been a better choice than LANMAN, because you allow arbitrary input passwords and thus good passwords are stronger instead of impossible even though MD5 is much too fast for a good password hash)
So e.g. computing a rainbow table for all possible Windows 2000 passwords (up to 14 characters but you're actually only doing 56-bit inputs) in the LANMAN scheme took ages, and produced a fairly large file, but having done so that's it, you, or anyone you give the file to, can reverse LANMAN hashes into working passwords almost instantly.
(Microsoft's LANMAN hash lacked salt, and is stupid in various other ways, MD5 would actually have been a better choice than LANMAN, because you allow arbitrary input passwords and thus good passwords are stronger instead of impossible even though MD5 is much too fast for a good password hash)
> Defense against rainbow tables is obtained via salt, not via slow hashes.
And bcrypt includes stores a unique salt next to the hash for every password, making rainbow tables completely useless.
https://en.wikipedia.org/wiki/Bcrypt
And bcrypt includes stores a unique salt next to the hash for every password, making rainbow tables completely useless.
https://en.wikipedia.org/wiki/Bcrypt
Nobody is saying bcrypt isn't a good choice here, they're saying that rainbow tables (and all time-space trades) are made infeasible by salt regardless of whether you're using a good password hash like bcrypt.
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 don't need to think about salts; you just call GenerateFromPassword(<new_password>) and CompareHashAndPassword(<entered_password>, <stored_hash>) and forget about it.
EDIT: I mean, I understand maybe why in 2006 you used md5 without salt. But a few years ago I when I tossed together my first webapp (a scheduling system for the community I'm involved in), I just googled "password hash" and immediately bcrypt came up as a recommendation; there was a package in my target programming language, so after half an hour of research and 5 minutes of programming I was done. I don't understand how the opensubtitles team, after having had their password database compromised, came up with "use sha256 without salt" instead of "use bcrypt or one of the many libraries which takes care of all of that for you".
EDIT: I mean, I understand maybe why in 2006 you used md5 without salt. But a few years ago I when I tossed together my first webapp (a scheduling system for the community I'm involved in), I just googled "password hash" and immediately bcrypt came up as a recommendation; there was a package in my target programming language, so after half an hour of research and 5 minutes of programming I was done. I don't understand how the opensubtitles team, after having had their password database compromised, came up with "use sha256 without salt" instead of "use bcrypt or one of the many libraries which takes care of all of that for you".
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 hash and got pointed to MD5 (or SHA1 or even SHA256) because that's what those are.
The words you should have googled weren't "password hash" but maybe "web authentication" and then the answer is clearly you shouldn't use passwords or any sort of shared secret.
You can have a copy of the authentication database for the toys system I maintain, but it wouldn't help you sign into it because all the information in it is public, a trick we've known how to do in principle for decades, and which works today, on the public Web, with readily available devices (e.g. my phone) and yet, here we are on Hacker News discussing which password hash is best like it's still 1985.
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 hash and got pointed to MD5 (or SHA1 or even SHA256) because that's what those are.
The words you should have googled weren't "password hash" but maybe "web authentication" and then the answer is clearly you shouldn't use passwords or any sort of shared secret.
You can have a copy of the authentication database for the toys system I maintain, but it wouldn't help you sign into it because all the information in it is public, a trick we've known how to do in principle for decades, and which works today, on the public Web, with readily available devices (e.g. my phone) and yet, here we are on Hacker News discussing which password hash is best like it's still 1985.
> 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.
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.
This, _and_ bcrypt is slow. Many wrapping libraries' hashing functions accept an optional parameter to specify just how slow it should be.
True, I might be mixing names. What I mean is that now with fast hashes it's feasible to take for each user and compute a table with the 1,000,000 most common passwords and their specific salt, and repeat for all the users. With a modern homemade GPU rigs making billions[1] of computations per second, you are testing thousands of users per second with a 1M word dictionary, so you are going to find matches.
[1] https://hackaday.com/2012/12/06/25-gpus-brute-force-348-bill...
[1] https://hackaday.com/2012/12/06/25-gpus-brute-force-348-bill...
Where do you store the salt?
The salt can be stored directly in front of the hash in the same string in the DB (a lot of crypto hash functions will output this). It can be plaintext since the goal is to add a random component so rainbow tables wouldn't be possible since there's always more to the string being hashed. That's where it becomes a time problem.
Yeah, you could rebuild a rainbow table yourself u til you find the collision, but you have to search every bit of the potential hash space.
Yeah, you could rebuild a rainbow table yourself u til you find the collision, but you have to search every bit of the potential hash space.
[deleted]
> I'm not sure if bcrypt/blowfish is still the recommended algorithm or there's newer better ones
While bcrypt is already much, much better than using MD5 or SHA256, the best practice is to use Argon2.
In practice, it is more important to use a hashing algorithm that is designed for passwords (e.g. bcrypt, argon2, scrypt) than it is to choose the best one. As this breach shows, many sites are still using insecure hashes, like MD5, because it worked 15 years ago.
While bcrypt is already much, much better than using MD5 or SHA256, the best practice is to use Argon2.
In practice, it is more important to use a hashing algorithm that is designed for passwords (e.g. bcrypt, argon2, scrypt) than it is to choose the best one. As this breach shows, many sites are still using insecure hashes, like MD5, because it worked 15 years ago.
Which mode do you/would you use? Hybrid?
I haven't had to write any password storage code since before Argon2 won the 2015 competition so I haven't gone deep on the "side channel attack vs. memory hardness" tradeoff question when picking the mode. I am curious which mode others are using.
I haven't had to write any password storage code since before Argon2 won the 2015 competition so I haven't gone deep on the "side channel attack vs. memory hardness" tradeoff question when picking the mode. I am curious which mode others are using.
Hybrid (Argon2id) is probably the safest bet if you are unsure.
The specific modes are useful dependent on the threat model you are protecting against. Argon2i protects better against timing/side-channel attacks and Argon2d protects better against brute-forcing attacks.
In my opinion, a developer should (in most cases) focus on application security instead of picking the perfect hashing algorithm, as application security is far more crucial.
The specific modes are useful dependent on the threat model you are protecting against. Argon2i protects better against timing/side-channel attacks and Argon2d protects better against brute-forcing attacks.
In my opinion, a developer should (in most cases) focus on application security instead of picking the perfect hashing algorithm, as application security is far more crucial.
Argon2ID
A properly implemented use of password_hash() would also allow them to use the same field and code for different algorithms over time.
What I mean is, the stored data contains which algorithms it is. So they can in their code or configuration change which algorithms to use and how many times it should hash. Then on login they can verify the password against the hash and also check if the stored hash needs to be rehashed against the current set settings, then it can create a new hash from the password the user entered on login and store that in the database.
Then you get automatic hash upgrades to match the current settings of the hashing of the passwords on the site with basically no user interaction (other than the act of logging in to have the password in plain text).
What I mean is, the stored data contains which algorithms it is. So they can in their code or configuration change which algorithms to use and how many times it should hash. Then on login they can verify the password against the hash and also check if the stored hash needs to be rehashed against the current set settings, then it can create a new hash from the password the user entered on login and store that in the database.
Then you get automatic hash upgrades to match the current settings of the hashing of the passwords on the site with basically no user interaction (other than the act of logging in to have the password in plain text).
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/
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/
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
This could also be problematic.
Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ
Ok, some text with a 3 lines explanation of the attack, instead of a 45 minutes video where it's explained somewhere in less than a second:
https://security.stackexchange.com/questions/234794/is-bcryp...
https://security.stackexchange.com/questions/234794/is-bcryp...
It can be a good migration strategy. Just make sure to fix it in first next Login of a user.
Still much better to have md5 directly in your db.
I fixed something like this just 4 years ago. :|
Still much better to have md5 directly in your db.
I fixed something like this just 4 years ago. :|
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.
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.
> > 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.
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.
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.
I wonder if adding a random salt for each account would help in that situation?.
bcrypt(md5(password) + salt) + salt
the problem with password shucking would be that they just do a bcrypt(md5) over the list of md5 hashes they have and check if they exist in your database.
but if each hash is salted they would need to run every their complete md5 hash list through bcrypt for each account instead of once per database.
bcrypt(md5(password) + salt) + salt
the problem with password shucking would be that they just do a bcrypt(md5) over the list of md5 hashes they have and check if they exist in your database.
but if each hash is salted they would need to run every their complete md5 hash list through bcrypt for each account instead of once per database.
No that wouldn't help because you'd need to store the random salt along the hashes. So you can still do: bcrypt(other_leaked_md5 + salt) to shuck it (i.e confirm if both are the same, and skip the bcrypt on your stronger service). The defense is a global "pepper" that would be in the code but not the DB, assuming only the second one leaks.
for md5, you could also download some common password lists and rehash at least the ones you can "crack"
Great idea, but seeing as you are rearchitecting you might as well add the salt to the MD5 while you are at it.
I believe that this is a great idea but I was kind of wondering why people are not resorting to this method?
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: <link to list of password managers>.
> We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and <list of punctuation>. 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.
> 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: <link to list of password managers>.
> We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and <list of punctuation>. 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.
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
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
> 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.
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.
Websites (like some banks used to) that have less-than 20 char limits for passwords are purely bad security strategy.
You know what the worst is? When they limit you to, say, 20 or 32 characters, but accept a longer password and silently truncate it!
I've run across that at least once and it was a total pain to troubleshoot and figure out.
I've run across that at least once and it was a total pain to troubleshoot and figure out.
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.
There needs to be a limit, yes, but surely something like 100 characters, or even 50, would be more sensible.
And it's the same websites that tend to use the bad practice of forcing the use of 2-4 "types" of characters...
like some banks used to
Banks all have systems that will stop you from attempting to bruteforce them.
Banks all have systems that will stop you from attempting to bruteforce them.
The CPU usage difference between a hash on 20 bytes vs 100 (assuming ASCII) can't be that bad, can it?
We are not talking about 100 bytes of password here, but megabytes of garbage. See https://www.djangoproject.com/weblog/2013/sep/15/security/, also known as CVE-2013-1443.
"A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher."
"A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher."
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.
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.
Exactly this, it’s a vector for DOS
> 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.
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.
I'm guessing folks are reading that as endorsement or sha256 over bcrypt. In context with the above post, this is sha256 over truncation.
> It is kind of amazing, that the site was hacked now, after 15 years - so that hacker must have spent quite a lot of time and energy on it.
I'm pretty sure that it did not take "that hacker" 15 years to find this vulnerability.
Pretty strange forum post.
I'm pretty sure that it did not take "that hacker" 15 years to find this vulnerability.
Pretty strange forum post.
Website still managed by a just graduated 21 year old?
he is not that young, roughly my age around 40 living in Ko Phangan
here are his videos since his website is dead and he is also not active on twitter anymore https://www.youtube.com/user/BranoGege/videos
here are his videos since his website is dead and he is also not active on twitter anymore https://www.youtube.com/user/BranoGege/videos
> Tue Jan 18, 2022 2:34 pm
> In August 2021 we received message on Telegram from a hacker, who showed us proof that he could gain access to the user table of opensubtitles.org, and downloaded a SQL dump from it.
Wait, they got proof in August and release the info only now? Was this because they were trying to be in a talk with the hacker? It wasn't really clear, but it's a long time...
> In August 2021 we received message on Telegram from a hacker, who showed us proof that he could gain access to the user table of opensubtitles.org, and downloaded a SQL dump from it.
Wait, they got proof in August and release the info only now? Was this because they were trying to be in a talk with the hacker? It wasn't really clear, but it's a long time...
They explain more here:
https://forum.opensubtitles.org/viewtopic.php?p=46845#p46845
https://forum.opensubtitles.org/viewtopic.php?p=46845#p46845
So, still a wrong procedure. They should have told everyone to renew their password and view them as compromised in August.
Edit: typo
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
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
I don't personally agree with paying the ransom but the logic seems sound.
If you pay them, they might keep their word. After all, how much would they get paid for a list of passwords compared to a ransom payment?
If you don't pay them, they are more likely to either sell or leak the lists.
In this case, although easy to say now, the correct answer is not to create public web applications until you know how to store passwords correctly and host databases securely, it's not like the information isn't readily available.
If you pay them, they might keep their word. After all, how much would they get paid for a list of passwords compared to a ransom payment?
If you don't pay them, they are more likely to either sell or leak the lists.
In this case, although easy to say now, the correct answer is not to create public web applications until you know how to store passwords correctly and host databases securely, it's not like the information isn't readily available.
Well, they hacked the website in the first place, what do they have to lose? I'd say paying the ransom might get back you your files, and that's about it. They can still have a copy and do whatever.
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
Never saw anyone suggest paying for avoiding password leaks
Which 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.
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.
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 third party implementation of the server in rust that seems to be mostly compatible. Both the official and the third party server are self-hostable.
BitWarden runs their infrastructure on Azure, uses Azure managed databases and Azure managed backups. So I'm quite comfortable having my passwords there.
The only feature I miss is that I'd like BitWarden to send me an email with all my passwords, encrypted so that I own a backup of my data too in case the worst happens.
BitWarden is open source, both server and clients. There's even a third party implementation of the server in rust that seems to be mostly compatible. Both the official and the third party server are self-hostable.
BitWarden runs their infrastructure on Azure, uses Azure managed databases and Azure managed backups. So I'm quite comfortable having my passwords there.
The only feature I miss is that I'd like BitWarden to send me an email with all my passwords, encrypted so that I own a backup of my data too in case the worst happens.
> 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.
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.
[0] https://support.google.com/mail/answer/7436150?hl=en
[0] https://support.google.com/mail/answer/7436150?hl=en
You could use your own domain, and Google's business offering maybe? I'm not sure if you could register a catch-all email then, but it would enable you to use custom domain, and Gmail's infrastructure and interface.
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.
> There's even a third party implementation of the server in rust that seems to be mostly compatible.
Not just mostly. Vaultwarden also offers server-side features usually only found in paid Bitwarden plans.
Not just mostly. Vaultwarden also offers server-side features usually only found in paid Bitwarden plans.
I use keepass with the app.keeweb.info frontend and a gdrive backend. keeweb.info has totp as well. Seems pretty straight forward and its free. Make the backend file accessible by link and forward a bit.ly to it and you can pull it down anywhere you have internet. Phone app works great too. Everything works offline too if gdrive isn't your thing
Every computer I normally use will have a copy of the file in the case that I can't access my gdrive (which I don't see happening really).
Every computer I normally use will have a copy of the file in the case that I can't access my gdrive (which I don't see happening really).
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 ridicule if it was ill-conceived, but I obviously rely on implementation details being tickety boo.
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 ridicule if it was ill-conceived, but I obviously rely on implementation details being tickety boo.
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).
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)
(I've used it quite successfully when it was in a separate app called Lockwise)
Bouncing via the system clipboard does feel a little sketchy, yes. The other is the password generation feature is entirely missing on Android, so I need to use another good source of randomn characters or delay until I'm at my desktop. It's really only these two features that are missing for me, but since I create new password relatively rarely (once or twice a month), I find just having it there to be the winning feature. Also the 'copy these random files' as a back-up mechanism for disaster recover seems a bit ... like something I would design, so not great.
Do we need to toggle this feature somewhere in the settings? I use KeepassDX but I've never been asked by the app to auto-fill in passwords on websites or other apps.
It's a separate keyboard, and needs to be enabled in the keyboard settings of Android. There's a link in the KeepassDX settings.
There is a separate autofill feature, but that works quite rarely, maybe 10% of the apps support that, but that makes things even easier.
There is a separate autofill feature, but that works quite rarely, maybe 10% of the apps support that, but that makes things even easier.
using chrome's manager and android 11 has native autofill for apps which works 100% so far
Use bitwarden (see related thread on HN today). Works great in Firefox, on mobile, Firefox mobile, etc. All synced. And it works in other browsers too.
Well, for this kind of negligible importance website risk management is simple : just use a variation on "password for opensubtitles" as a password (and maybe even have it saved by your browser).
(If like me, you find the idea of a password manager not acceptable.)
(If like me, you find the idea of a password manager not acceptable.)
Agreed. If they don’t have anything personal but my email address, I use a password that’s been compromised and reused for 10 years but easy to remember. Weigh the risk and exposure against.
> 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.
to his defense it's not like there is anything serious stored there with those accounts, it's just subtitles
It's not just subtitles - it's all the login information stored there as well. Email addresses to send spam to, passwords that have likely been reused on another site.
and how is you reusing password to download subtitles (it ain't even necessary really) problem of the hacked site?
yes spam could be annoying, but it's not like people use email only to register on one site
yes spam could be annoying, but it's not like people use email only to register on one site
>On the technical side, he was able to hack the low security password of a SuperAdmin, and gained access to an unsecured script, which was available only for SuperAdmins. This script allowed him to perform SQL injections and extract the data.
It can be tempting to forgo the same security considerations when programming backend applications which aren't ordinarily accessible to the public. I guess this is a reminder why the temptation must be resisted.
It can be tempting to forgo the same security considerations when programming backend applications which aren't ordinarily accessible to the public. I guess this is a reminder why the temptation must be resisted.
> The site was created in 2006 with little knowledge of security, so passwords were stored in md5() hashes without salt
Ouch!
I hope they learned their lesson: Security is an ongoing effort.
Ouch!
I hope they learned their lesson: Security is an ongoing effort.
16 years without reviewing password security seems like a massive oversight. A major leak like this it's a high price to pay to learn this lesson.
The really bad thing is that md5 was considered broken in 2005 by security people like Bruce Schneier.
To be fair to them it took till around 2008 for this to become widespread opinion but the signs were on the wall around 2004
To be fair to them it took till around 2008 for this to become widespread opinion but the signs were on the wall around 2004
You believe sha256 would drastically improve password hashing, being a not broken hash function? In 2006 they likely ran php4 and didn't have much choice what hash to use.
for 2006 that's actually not bad.
When I joined my first company in 2010, to my horror, they were using plain text passwords for users
When I joined my first company in 2010, to my horror, they were using plain text passwords for users
My first company was using MySQL’s OLD_PASSWORD() function in 2013 — straight, with no salt or spice of any kind — in its 64-bit glory. Horrified, I did some research and threw bcrypt up there right away. Not sure if it was my my first commit, or the branch fixing 20 or so SQLIs was the first. I became my company’s software security expert out of sheer terror.
Yeah, just last month I was shocked to see a shop where I forgot my 2017 password, to send it to me. in plain text. by e-mail. (at least IIRC they used HTTPS on their website !)
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.
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.
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.
Open subtitles does require a pw change, it broke mplayer integration.
Funny, though, they got breached approximately an hour after I went VIP - it's the only way to download an entire season of subtitles, and their maint window correlates to me having spotty subtitle coverage across most of my library. So I gave in and gave money.
Then it's like "invalid password!"
Funny, though, they got breached approximately an hour after I went VIP - it's the only way to download an entire season of subtitles, and their maint window correlates to me having spotty subtitle coverage across most of my library. So I gave in and gave money.
Then it's like "invalid password!"
I thought their response to this was very humble, and I wish them the best going forward.
Reading 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 burned in a dumpster like the dumpsterfire of security they had running for fucking 15 years.
(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 burned in a dumpster like the dumpsterfire of security they had running for fucking 15 years.
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
> 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
By now I assume that any service where I've registered for an account is being actively targeted and that any organisation that's not a Google, Microsoft or the likes has already been breached. MFA is your friend, and even plain vanilla SMS based MFA is better than just a username and password for authentication. I've enabled hardware based MFA anywhere it's supported.
15-20 years ago it was fun to sign up for dozens of new services and we reused passwords everywhere. Now every one of these accounts is a liability and a potential vector for bad things to happen. The worst case scenario is when an account of yours is breached and abused for a long time, possibly with legal and financial ramifications, and you don't find out until much later.
A couple of months ago I happened to glance at my Gmail's spam folder by chance, and one email way down the list immediately grabbed my attention. The subject line had *my password* for an old and unused account that I'd forgotten long back and the sender was trying to extort bitcoin if I wanted the account back.
The big issue is with online shopping. The sender has your name, address, email, phone number and possibly your CC number, a prime target for identity thieves.
15-20 years ago it was fun to sign up for dozens of new services and we reused passwords everywhere. Now every one of these accounts is a liability and a potential vector for bad things to happen. The worst case scenario is when an account of yours is breached and abused for a long time, possibly with legal and financial ramifications, and you don't find out until much later.
A couple of months ago I happened to glance at my Gmail's spam folder by chance, and one email way down the list immediately grabbed my attention. The subject line had *my password* for an old and unused account that I'd forgotten long back and the sender was trying to extort bitcoin if I wanted the account back.
The big issue is with online shopping. The sender has your name, address, email, phone number and possibly your CC number, a prime target for identity thieves.
> even plain vanilla SMS based MFA is better than just a username and password for authentication
I'd be careful with this because a lot of services will allow you to reset your password with just SMS verification once they have your number. So while Password+SMS is stronger in practice this usually becomes Password+SMS OR Customer Support+SMS which is decidedly weaker.
I'd be careful with this because a lot of services will allow you to reset your password with just SMS verification once they have your number. So while Password+SMS is stronger in practice this usually becomes Password+SMS OR Customer Support+SMS which is decidedly weaker.
About 10 years ago I found this feature of Gmail where you could see the login history, with lots of entries with IPs from China, the US and various other countries. That really drove the point home for me. Since then it's all unique passwords stored in Keepass. And it still doesn't feel 100% secure.
My old outlook account receives log in attempt every ~5mins (!!) from all over the world. It's actually crazy that the attempts have not stopped after failing for so long, probably indicates it's from different attackers. The email has been on a couple of leaks but even then, the sheer amount of attempts is so crazy that I'd assume they are using a lot of password leaks that aren't publicly known yet.
It is very annoying how more and more shops force you to give a phone number... IMHO (unless product defect) only the transporter should get that !
Twitch (Authy), eBay and Amazon come to mind as the most annoying examples. My god just give me TOTP or stop pestering me for my number. eBay is so idiotic that it even asks for security questions. The 2000s called, they want their obsolete security back.
At one point I think you could use opensubtitles.org without a username and password. I wonder in hindsight if the liability of storing PII was worth it?
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
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
Spam was one reason (I've actually asked to the admins, which were very pissed off by it).
Not very reassuring that when you reset your password they send you a new one in plaintext over email....
I've lost a lot of trust in opensubtitles since they started going down for "scheduled maintenance" for about two hours a day during the west coast evening, started selling advertising in the middle of the subtitles, and launched a "2.0" in the form of opensubtitles.com that continues to have a confusing and poorly described relationship with opensubtitles.org.
The whole thing has just given a solid impression of being poorly managed, and the way this breach notification is written really reinforces that. It's unfortunate as I would be happy to donate money but... not to opensubtitles, which seems to be too deep in a hole to realistically get back out of it.
The whole thing has just given a solid impression of being poorly managed, and the way this breach notification is written really reinforces that. It's unfortunate as I would be happy to donate money but... not to opensubtitles, which seems to be too deep in a hole to realistically get back out of it.
I love the concept of OpenSubtitles, but they seem to have a hard time maintaining centralized infrastructure. I don't really understand why downloads are zipped in 2022 when GZIP over HTTP is plenty efficient: maybe it's for backend storage space, though?
Is there some way we could help OpenSubtitles decentralize and maintain a p2p or federated database of subtitles? This could probably prevent many modes of failure that have required to restrict access to the API over time.
Is there some way we could help OpenSubtitles decentralize and maintain a p2p or federated database of subtitles? This could probably prevent many modes of failure that have required to restrict access to the API over time.
I wonder how the hacker got network access to the database? I couldn't work out from what I read. It said the DB had a weak superuser password. But it didn't say how the hacker managed to make network calls to the DB. Presumably there was some initial entry point to get inside the network? It sounds like maybe the web-application user verification was poor and the app allowed admin users to make arbitrary DB calls?
> was able to hack the low security password of a SuperAdmin, and gained access to an unsecured script, which was available only for SuperAdmins. This script allowed him to perform SQL injections and extract the data.
Depending on the injection vulnerability data can be exfiltrated, there are tools like sqlmap https://sqlmap.org/ which make it pretty easy to dump tables via injection
Depending on the injection vulnerability data can be exfiltrated, there are tools like sqlmap https://sqlmap.org/ which make it pretty easy to dump tables via injection
Is 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?!)
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?!)
There's a python "app" called subliminal (with a simple CLI) that handles the whole enchilada for you - identify the movie, contact several subtitle dbs to download the appropriate subtitles.
Not sure how up-to-date it is kept, but for me it works reasonably well, except for obscure films.
https://github.com/Diaoul/subliminal
Not sure how up-to-date it is kept, but for me it works reasonably well, except for obscure films.
https://github.com/Diaoul/subliminal
I use opensusbtitles only through VLsub in VLC, if I have to go somewhere on my own (no susbs found on OS in VLC) I go to subscene
> (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.
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.
This is another example of why we should use a unique email address and password for each account. If credit card is needed, use a virtual card. Otherwise one breach exposes our other accounts to compromise. anonaddy.com, simplelogin.com, and privacy.com are some of the services that help with this.
Alright, changed my password, and to mitigate the issue I tried switching the email to a disposable one (@mozmail.com) and never received the email confirmation to apply the change.
Looks like I'll just delete my account and never come back then.
Looks like I'll just delete my account and never come back then.
Using md5 with no salt while providing paid services and obviously earning income, but in 15 years not even a basic security check? At this point, the web is becoming ridiculous, and stuff like this should be sanctioned.
Why do we learn that passwords are obsolate and webauthn is the only sane choice?
I believe webauthn requires end users to perform key management. I suspect that is currently a harder task for the average user than a memorized or written-down password. Special hardware tokens may help, but I'm not sure how we'd convince average users to care or buy them.
Are there any webauthn only sites, besides demos?
Are there any webauthn only sites, besides demos?
The end user's agent (browser) should handle the key management behind the scenes. Even without hardware tokens it's still at least as good as a software-based password manager. A Hierarchical Deterministic key system similar to the BIP32 scheme used by most Bitcoin wallets[0] would only require a single master private key per user to support any number of unrelated identities. That key could be generated from a master password, synced to each device through an enrollment process, or stored on a hardware token.
[0] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
[0] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
This is new to me, thanks.
Do you know how that supports use cases like if someone wants to change their flight from a hotel computer? I wouldn't want to expose a "master password" to a computer I didn't trust.
Do you know how that supports use cases like if someone wants to change their flight from a hotel computer? I wouldn't want to expose a "master password" to a computer I didn't trust.
If you don't trust the computer then your best option is a hardware token like the Trezor (which already supports WebAuthn in addition to its cryptocurrency functions). The better ones will include a screen where you can see details like which site you're signing into before confirming the request. Either way, the host computer never gets access to any private keys. It can still do whatever it wants with your login session on that site, though, so you'll want to be careful about logging in to sensitive sites from untrusted PCs. The same applies to password-based logins, of course; moreover, any password you've entered into a public PC should immediately be considered compromised and changed (from a secure device) at the earliest opportunity.
Given any choice in the matter I would suggest using your own equipment to change the flight (e.g. a smartphone), even if it's less convenient.
Given any choice in the matter I would suggest using your own equipment to change the flight (e.g. a smartphone), even if it's less convenient.
> The site was created in 2006 with little knowledge of security, so passwords were stored in md5() hashes without salt
Read as: In the last fifteen years we couldn't be bothered to fix our glaring security hole.
Read as: In the last fifteen years we couldn't be bothered to fix our glaring security hole.
I already knew about this before I visited HN today, thanks to Firefox Monitor ( https://monitor.firefox.com/ ) :D
Bahaha I made an account a few days ago! So glad I used a throwaway email.
I recommend subscene.com for a no-hassle way to download subtitles.
Tangentially 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 how scary keeping passwords seems to have been made.
I guess my real question is: If I'm hashing with an actual password acceptable hash method (salt and all), is there any reason I shouldn't still do this? I'm legitimately interested, because for all I know, I'm experiencing the Dunning-Kruger effect.
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 how scary keeping passwords seems to have been made.
I guess my real question is: If I'm hashing with an actual password acceptable hash method (salt and all), is there any reason I shouldn't still do this? I'm legitimately interested, because for all I know, I'm experiencing the Dunning-Kruger effect.
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?
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?
You did right: no need to pay the ransom.
I'm confused. Didn't he say that he DID pay the ransom?
My bad, you are right.
He said they paid.
The short history of ransomware shows whenever the ransom was paid, the attackers came back again to threat and solicit more money. It's advised not to pay. But only the business owners could have the right "feeling" as they are the only ones who communicated with the attacker(s)
Again!
They just had a breach like 4 months ago
They just had a breach like 4 months ago
>The site was created in 2006 with little knowledge of security, so passwords were stored in md5() hashes without salt
That's a good excuse for it to be like this in 2006. What about 2021?
That's a good excuse for it to be like this in 2006. What about 2021?
What is the motivation to run this non profit site? I can not believe the motivation can simply be to get subtitles to watch movies personally. I suspect this is not really non profit as there the site supports ads. My guess is the owner is making decent money via ads. To the readers of this comment, if you can make a rough calculation of the ad revenue with good assumptions to validate or invalidate my theory, that would be amazing. Thanks HN
> I can not believe the motivation can simply be to get subtitles to watch movies personally
Why can't it be? Does everything require a money motive? Is it impossible that people want to do something good?
Why can't it be? Does everything require a money motive? Is it impossible that people want to do something good?
> Does everything require a money motive?
On HN, apparently. See the recent thread on Wordle.
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. The warez scene is a subculture and community for the people who participate in it.
It is depressing that HN participants are so often mystified by the idea people might be motivated by intrinsic or social factors to engage in peer-based production (whether legal or not) when so many of the companies they run or work for exist only because of peer-based production efforts like Linux and other FOSS software.
On HN, apparently. See the recent thread on Wordle.
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. The warez scene is a subculture and community for the people who participate in it.
It is depressing that HN participants are so often mystified by the idea people might be motivated by intrinsic or social factors to engage in peer-based production (whether legal or not) when so many of the companies they run or work for exist only because of peer-based production efforts like Linux and other FOSS software.
> 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.
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.
> according to their CV, this is basically their job. That'd make Opensubtitles a for-profit piracy site, i guess.
Guess what: Non-profit != for-free && Non-profit != for-a-loss.
If in order for opensubtitles to fulfill its envisioned role needs full-time attention, it is legit to pay yourself or hire an employee, paid by the ad and or subscription money. That's what also happens on all registered non-profit organizations.
Guess what: Non-profit != for-free && Non-profit != for-a-loss.
If in order for opensubtitles to fulfill its envisioned role needs full-time attention, it is legit to pay yourself or hire an employee, paid by the ad and or subscription money. That's what also happens on all registered non-profit organizations.
Yeah, I saw it had a subscription model for VIP users. I'm guessing they're not getting Jeff Bezos, Bill Gates level rich off it though.
Subtitles aren't piracy in any way though. Kind of similar to legality of torrent sites but even less questionable.
I don't think they're implying the subtitles themselves are piracy, but the users of opensubtitles.org are overwhelmingly using them for pirated media. The subs are all indexed against scene versions of the video files (as you can tell from their names), and that's what most users are using it for. After all, streaming services, DVDs, and other legitimate ways of consuming these shows/movies already come with subtitles.
No, the 0.1% of subs for obscure indie shows that didn't have native subs doesn't change that.
No, the 0.1% of subs for obscure indie shows that didn't have native subs doesn't change that.
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.
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.
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.
You want to double check your math there?
Hahh, "I don't need a calculator" :) Regardless, I can't find the source, but I remember reading that this site is a cash cow.
I should have been more clearer. Please see my other comment https://news.ycombinator.com/item?id=29991505 for clarification. I am glad to see comments like yours at HN honestly.
Well, not when licensed entertainment is involved. Subtitles may sound harmless but are enough to start a court battle. This happened in Poland with a similar site. I would not dare to claim that authors motives and all actions were clean and done in the open, but for sure they were targeted by various media groups for copyright infringement just because of plain subtitles.
You need resources to deal with that and it's not gonna be a clean fight.
You need resources to deal with that and it's not gonna be a clean fight.
I should have been more clearer. I can understand running a hobby site to chat with fellow hobbyists which is a motivation for socializing. In this case its pretty much static. I fail to understand the motivation.
Opensubtitles is definitely for-profit. They sell lots of ad space, including ads injected into the subs themselves.
These days a lot of the subtitle files actually have ads embedded in the text itself, either during the movie or at the beginning/end.
hahahaha, I know personally owner of the site and trust me it's VERY MUCH for profit site making him decent income for last 15 years living in Thailand travelling around world scubadiving and having fun
it's not just ads, but also paid API access AFAIR
nothing wrong with that, just not sure where you come with idea he would bother, if there would not be good money in it
it's not just ads, but also paid API access AFAIR
nothing wrong with that, just not sure where you come with idea he would bother, if there would not be good money in it
I've only ever interacted with it after account setup year ago via a rpi running Kodi which automatically downloads subtitles now and then, unless specifically searching for different versions barely remember it exists. I hope they make money somehow but get the feeling it's mostly just a bunch of api leeches like myself.
I don't understand such a website anyway. A website like OpenSubtitles seems like overkill for passing around text and timestamps. Why not use something like GitHub? Why couldn't the project simply be a big git repo? It would even be easier.
This is a little bit like saying Dropbox could just be a git repo. Yes, it could, but normal users don't know how to use git, and it adds features that git by itself doesn't provide.
Not to mention having this on GitHub would probably get taken down almost instantly due to copyright infringement.
Not to mention having this on GitHub would probably get taken down almost instantly due to copyright infringement.
Because the text is ultimately copyrighted and it would get DCMAed immediately.
edit: at the time I also was young and naive [0] and thought the open part of opensubtitles meant that people submitted subtitles in their free time out of their good heart and the site was simply hosting and organizing them, no problem with displaying ads on the website or at the beginning of the subs I thought, to make up for hosting costs. Subs hunting was so much fun at the time /s. But having to register to "prevent abuse" was a tad too much.
[0] still am by the way, thanks for asking :)