161–170 of 199 posts
Earlier quoted context omitted.
dang - ping! (I think he has a regex!)
Needs some sophisticated language parsing to filter out expressions of mild disappointment.
Earlier quoted context omitted.
Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.
Yes, but even if you allow it to only take 1ms per check for an attacker, it's still practical for you and will take an attacker 4 minutes per account to check all of /usr/share/dict/words (to say nothing of the "add a 1 or a ! at the end"), so long as you are using random per-account salt (which bcrypt basically guides you towards). Make it 15ms for an attacker and it becomes an hour per account just for the diction…
You also can't assume that all accounts are equally valueable. An attacker might very well prioritize some of them.
This doesn't render all of this useless but I think you shouldn't consider even best solutions out there to be anything else than a temporary barrier. It's a good one and you probably will have enough time to change your password after a leak but you really do need to change your password within a week or so.
Earlier quoted context omitted.
> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."
The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU…
To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.
Earlier quoted context omitted.
>Can someone change the op's link to: > https://www.leakedsource.com/blog/twitter No, let's not. First of all, leakedsource has already been submitted separately, but has fewer upvotes. Presumably people prefer the techcrunch version. It's not really surprising, as leakedsource's article is poorly laid out. It doesn't even have a title (they've put "Preface" as a title, but that's the heading of the first section). T…
>t doesn't even have a title (they've put "Preface" as a title, but that's the heading of the first section). Then there's the banner adverts at the top. The title of the page is "LeakedSource Analysis of Twitter.com Leak". I know it's the title because it's in the title tags. The appearance of banner ads is a strange criticism when comparing to a techcrunch page, which is essentially one huge ad for other tech tablo…
You're right about the adverts. It's more of a design thing than anything else. The site looks like it was designed in the 90s.
As for statements from twitter and others, they are very important, as they give credibility and background to the story. Most people here don't have time to do their own analysis and research on a story.
Just got the email: Your account may have been compromised by a website or service not associated with Twitter. I'd like to know how Twitter credentials were compromised from outside Twitter.
Like they said in the article, Twitter uses bcrypt to store your password, but many of the passwords in the dump were plain text. This suggests that they were scraped together from external sources (i.e. malware on your machine, re-use of a password from one of the other dumps like LinkedIn). Hence, compromised from outside Twitter.
Maybe the malware authors are processing and leaking the data per-website for monetization purposes?
Another way would be that only a specific twitter app has been targeted by the malware.
Just got the email: Your account may have been compromised by a website or service not associated with Twitter. I'd like to know how Twitter credentials were compromised from outside Twitter.
Does anyone know the significance of the date 9-11-1961? The password list has 10,444 matches for "9-11-1961" and 10,231 for "9111961". From Wikipedia, I see that Hurricane Carla hit Texas that day but that doesn't seem noteworthy enough to warrant two instances of the date in the top 20, It would be surprising if it was only due to date of birth too, given I can't spot any other date-like entries.
I was wondering the same thing "cepetsugih" and "exigent" seem like odd ones too
Earlier quoted context omitted.
> depending on work factor Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."
The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password? Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU…
Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased?
I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.
Earlier quoted context omitted.
It would allow you to bruteforce the passwords without any sort of rate limiting. So, if you used a dictionary, you probably could get quite a few weak passwords in a short amount of time relative to a system that had proper rate limiting to prevent these kinds of attacks.
Depends what you mean by short amount of time. Depending on the strength selected with bcrypt, it can easily take a second to check a hash. On a 30m password database, this will take a year on one machine to check just who is using "monkey" as a password.
Earlier quoted context omitted.
What problems with bcrypt/scrypt does argon2 solve?
bcrypt is limited to 72 characters (admittedly this is not that big a practical limitation), and scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence. In practice, they're still both great, but that doesn't mean we should stop trying to do even better. Argon2 looks really interesting, but it is still relatively new.