[HN Gopher] Opensubtitles.org breached - Email addresses, IP add...
___________________________________________________________________
Opensubtitles.org breached - Email addresses, IP addresses,
Passwords, Usernames
Author : aero-glide2
Score : 260 points
Date : 2022-01-19 05:06 UTC (17 hours ago)
(HTM) web link (forum.opensubtitles.org)
(TXT) w3m dump (forum.opensubtitles.org)
| eximius wrote:
| Bahaha I made an account a few days ago! So glad I used a
| throwaway email.
| tlhunter wrote:
| > 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.
| m3adow wrote:
| > 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.
| burai wrote:
| 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.
| foxtrottbravo wrote:
| 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
| ilogik wrote:
| 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
| BlueTemplar wrote:
| 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 !)
| labster wrote:
| 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.
| PikachuEXE wrote:
| 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.
| BlueTemplar wrote:
| 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.)
| TedDoesntTalk wrote:
| 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.
| verytrivial wrote:
| 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.
| wasmitnetzen wrote:
| 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?
| chompychop wrote:
| 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.
| wasmitnetzen wrote:
| 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.
| KwanEsq wrote:
| 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)
| verytrivial wrote:
| 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.
| ufo wrote:
| 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).
| jillesvangurp wrote:
| 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.
| carlhjerpe wrote:
| 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.
| COGlory wrote:
| Is exporting your passwords and encrypting the file not an
| option for you?
| carlhjerpe wrote:
| Well yes and no, I'd like it to be automatic but I have an
| old archive around somewhere.
| diarrhea wrote:
| > _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.
| g19fanatic wrote:
| 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).
| gck1 wrote:
| > 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.
| carlhjerpe wrote:
| 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.
| dzmien wrote:
| 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
| toyg wrote:
| _> TOTP integrated into the password manager_
|
| Is this portable, like Authy does it? Last time I moved phone
| it was a real pain to move authenticators...
| carlhjerpe wrote:
| Yes, you have the same TOTP keys in both your phone and
| browser ext
| throwaway834343 wrote:
| 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
| nano9 wrote:
| 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.
| Liquid_Fire wrote:
| 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.
| erklik wrote:
| > 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?
| lawtalkinghuman wrote:
| > 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.
| throwaway834343 wrote:
| 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.
| johndoeee wrote:
| > 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.
| m000 wrote:
| > 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.
| lawtalkinghuman wrote:
| 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.
| k4rli wrote:
| Subtitles aren't piracy in any way though. Kind of
| similar to legality of torrent sites but even less
| questionable.
| draugadrotten wrote:
| 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.
| apetresc wrote:
| 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.
| tiborsaas wrote:
| 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.
| weird-eye-issue wrote:
| 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
| tiborsaas wrote:
| $1 / 1000 visitor is $110k / month with 11 million
| visitors which agrees with my estimation.
| weird-eye-issue wrote:
| You want to double check your math there?
| tiborsaas wrote:
| 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.
| throwaway834343 wrote:
| 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.
| szszrk wrote:
| 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.
| Grimburger wrote:
| 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.
| Markoff wrote:
| 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
| causi wrote:
| 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.
| FDSGSG wrote:
| Opensubtitles is definitely for-profit. They sell lots of ad
| space, including ads injected into the subs themselves.
| exotree wrote:
| I thought their response to this was very humble, and I wish them
| the best going forward.
| gattilorenz wrote:
| > 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...
| Deukhoofd wrote:
| They explain more here:
|
| https://forum.opensubtitles.org/viewtopic.php?p=46845#p46845
| wasmitnetzen wrote:
| So, still a wrong procedure. They should have told everyone
| to renew their password and view them as compromised in
| August.
|
| Edit: typo
| gattilorenz wrote:
| > 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
| aniforprez wrote:
| 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
| lbriner wrote:
| 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.
| gattilorenz wrote:
| 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
| emptysongglass wrote:
| 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
| m-p-3 wrote:
| 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.
| j1elo wrote:
| 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
| piechlediech wrote:
| 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.
| darau1 wrote:
| Interesting. The service I use isn't there lol I'm afraid to
| tell anyone, now, lest it be put on the list.
| null4bl3 wrote:
| Again!
|
| They just had a breach like 4 months ago
| sneeds wrote:
| > 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.
| Markoff wrote:
| to his defense it's not like there is anything serious stored
| there with those accounts, it's just subtitles
| mnw21cam wrote:
| 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.
| martin_a wrote:
| > 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.
| Aeolun wrote:
| Website still managed by a just graduated 21 year old?
| diarrhea wrote:
| A prodigy at 6 years old back in the day.
| Markoff wrote:
| 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
| jcrawfordor wrote:
| 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.
| m-p-3 wrote:
| 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.
| foxtrottbravo wrote:
| 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.
| foxtrottbravo wrote:
| 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
| steviedotboston wrote:
| Not very reassuring that when you reset your password they send
| you a new one in plaintext over email....
| iqanq wrote:
| >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?
| korginator wrote:
| 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.
| BlueTemplar wrote:
| 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 !
| Avamander wrote:
| 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.
| kevincox wrote:
| > 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.
| stef25 wrote:
| 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.
| mardifoufs wrote:
| 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.
| shaan7 wrote:
| I already knew about this before I visited HN today, thanks to
| Firefox Monitor ( https://monitor.firefox.com/ ) :D
| franciscop wrote:
| > 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
| joren485 wrote:
| > 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.
| brobinson wrote:
| 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.
| joren485 wrote:
| 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.
| fernovus wrote:
| Argon2ID
| woutifier wrote:
| 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).
| stef25 wrote:
| Where do you store the salt?
| jjice wrote:
| 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.
| [deleted]
| gwd wrote:
| > 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
| tialaramex wrote:
| 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.
| gwd wrote:
| 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".
| tialaramex wrote:
| 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.
| gwd wrote:
| > 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.
| dotancohen wrote:
| This, _and_ bcrypt is slow. Many wrapping libraries'
| hashing functions accept an optional parameter to specify
| just how slow it should be.
| franciscop wrote:
| 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...
| tialaramex wrote:
| 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)
| etu wrote:
| 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).
| mooreds wrote:
| 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/
| AdmiralAsshat wrote:
| 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.
| Jnr wrote:
| 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.
| YPPH wrote:
| >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.
| stubish wrote:
| 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?
| pizza234 wrote:
| I think one use case was subtitle downloading (typically, a
| client like Subdownloader) for VPN users, whose requests would
| be denied if unauthenticated.
| pferde wrote:
| 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?
| pizza234 wrote:
| Spam was one reason (I've actually asked to the admins,
| which were very pissed off by it).
| drexlspivey wrote:
| 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/vi
| ewtopic.php?f=11&t=17110)
|
| We are actively blocking IPs, which are sending
| unathenticated requests
| johnchristopher wrote:
| 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). I
| always forgot about login details and in my opinion it wasn't
| needed at all for them except for profile tracking I guess. They
| forced people to register to get subtitles, they willingly forced
| people to increase their attack surface for not much benefits to
| users (and probably themselves).
|
| 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 :)
| mkdirp wrote:
| > 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.
| stevenwoo wrote:
| The website began to require login within the last three days
| for me.
| morrbo wrote:
| Can you name a few please?
| Liquix wrote:
| https://github.com/a4k-openproject/a4kSubtitles
|
| anonymous, scrapes a handful of sites including
| opensubtitles + subscene
| johnchristopher wrote:
| I am confused, the GIF show a login+password for
| opensubtitles https://camo.githubusercontent.com/a1cd19d1
| 7f0484669e61673fa....
|
| Oh, well. I'll give a try next time I launch kodi, thanks
| for the tip.
| mkdirp wrote:
| It says "Optional" next to the username/password.
| Markoff wrote:
| 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
| johnchristopher wrote:
| 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.
| spamtarget wrote:
| 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
| m-p-3 wrote:
| I downloaded the SRT, stripped the ads using SubtitleEdit and
| embedded them in the MKV file using MKVToolNix to keep it all
| together.
| begueradj wrote:
| You did right: no need to pay the ransom.
| baobabKoodaa wrote:
| I'm confused. Didn't he say that he DID pay the ransom?
| begueradj wrote:
| 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)
| kornhole wrote:
| 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.
| Aissen wrote:
| 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.
| stevewodil wrote:
| 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
| 8organicbits wrote:
| > 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.
| 8organicbits wrote:
| I'm guessing folks are reading that as endorsement or
| sha256 over bcrypt. In context with the above post, this is
| sha256 over truncation.
| tzs wrote:
| 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.
| DrBoring wrote:
| > 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.
| ThreeToZero wrote:
| 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.
| GordonS wrote:
| 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.
| BlueTemplar wrote:
| And it's the same websites that tend to use the bad
| practice of forcing the use of 2-4 "types" of
| characters...
| userbinator wrote:
| _like some banks used to_
|
| Banks all have systems that will stop you from attempting
| to bruteforce them.
| mooreds wrote:
| 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.
| colejohnson66 wrote:
| The CPU usage difference between a hash on 20 bytes vs 100
| (assuming ASCII) can't be that bad, can it?
| mooreds wrote:
| 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
| l-lousy wrote:
| I think an average user password would be shorter than a
| sha256 hash no?
| LeifCarrotson wrote:
| 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.
| dabeledo wrote:
| > simply do bcrypt(md5(password))
|
| This could also be problematic.
|
| Password Shucking https://www.youtube.com/watch?v=OQD3qDYMyYQ
| marcosdumay wrote:
| 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...
| kobalsky wrote:
| 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.
| Aissen wrote:
| 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.
| Shamii wrote:
| 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. :|
| mpeg wrote:
| 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.
| Perseids wrote:
| 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.
| asddubs wrote:
| for md5, you could also download some common password lists and
| rehash at least the ones you can "crack"
| danhoule wrote:
| I believe that this is a great idea but I was kind of wondering
| why people are not resorting to this method?
| fps-hero wrote:
| Great idea, but seeing as you are rearchitecting you might as
| well add the salt to the MD5 while you are at it.
| jjice wrote:
| 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.
| web007 wrote:
| 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?
| sysadm1n wrote:
| 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?!)
| Markoff wrote:
| 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
| sodality2 wrote:
| > (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.
| FabHK wrote:
| 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
| theplumber wrote:
| Why do we learn that passwords are obsolate and webauthn is the
| only sane choice?
| 8organicbits wrote:
| 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?
| nybble41 wrote:
| 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.medi
| awi...
| 8organicbits wrote:
| 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.
| nybble41 wrote:
| 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.
| morelish wrote:
| 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?
| mustardo wrote:
| > 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
| morelish wrote:
| Ah I see, it was the website user SuperAdmin the hacker got
| into. Cheers.
| mustardo wrote:
| Thats my understanding, I initially thought MySQL root user
| as well
| gsich wrote:
| I recommend subscene.com for a no-hassle way to download
| subtitles.
___________________________________________________________________
(page generated 2022-01-19 23:02 UTC)