Yeah, the general assumption is, “If they could get to your database, they likely got to your code as well.”
1 Like
Using an NDA is not enough, as it only requires the 3rd party (your researcher in this case) not to disclose the data. It does not require destruction of the data after the task, or prohibit illegitimate use of the data. You need a Data Processing Agreement.
So we’re not worried, at least for now, about trade secrets or other privileged information being revealed, since they were all public posts anyway. If we were, that’s a whole other blog post I can write at a later date.
@codinghorror - I would really love to hear your thoughts on how to effectively run a private Discourse forum containing “privileged information”. I may or may not already be doing that, and in my enthusiasm for Discourse I may or may not have already told the badguys about it:
I may be a little bit late, but here are my 2ct anyways: Argon2 won the password hashing competition back in 2015. From the website:
PHC ran from 2013 to 2015 as an open competition—the same kind of process as NIST’s AES and SHA-3 competitions, and the most effective way to develop a crypto standard. We received 24 candidates, including many excellent designs, and selected one winner, Argon2, an algorithm designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich from University of Luxembourg.
We recommend that use you use Argon2 rather than legacy algorithms. You’ll find the specifications and reference code just below.
The panel selecting the winner included quite many well known cryptographers (see the website for the full list) and all candidates underwent a thorough public analysis (see the final report for a summary). HTH
Yes but winning a competition is not the same as being under attack in the real world for 5-10 years. Far from it…
1 Like
Another great analysis. I love the kind of thought y’all bring to this whole project.
It seems crazy that Qwerty1234 and Qwertyuiop1 aren’t in the list of 10k most common passwords.
The gains from many recent hacks are publicly available containing hundreds of millions of actual passwords-- check out weakpass.com for example. In their top 100k login list, qwerty1234 was 2k in and qwertyuiop123 37k in.
Part of the answer might be to block more of these terrible passwords. Scanning down the weakpass.com list past 10k, I see awful passwords like “thunderbird”, “jediknight”, and “imhorny” all the way down at 19k.
But that won’t do it-- down at 26k is qq123456789. Perhaps login to block sequenial number sequences makes sense, too. And keys in sequence and/or repeating on a qwerty keyboard, like at 97k, “asdasdasdasd”. But you can keep going down the rabbit hole with that sort of rules-based classification and eventually you end up writing your own Spamassassin only to be obsoleted by a machine learning bayesian algorithm shortly thereafter.
It’s great that you’re making it harder to hash, and Imma let you finish there, but in addition to that, to best serve your users, you should support two-factor authentication and make it mandatory for admins and moderators (where you host) and both strongly encourage it and make it very easy to implement elsewhere.
That’s what the library does - instead of producing just a hash string, it produces a delimited string containing sections to specify the hash method, salt, and hash. This is to:
- Be able to support having a database column that stores multiple different types of hashes
- Be able to handle upgrades and changing the hashes and parameters like iterations
- Make the data portable among systems that use the same format
It’s designed to support multiple hashing methods and transparent upgrades.
Can be used to rehash hashes of a broken method using a newer method, (so that they’re not easily vulnerable in the meantime) and then when the user logs in again it knows to double up (old method then new method) to check, then replace that with a fresh hash using the new method.
How fast is hashcat at just generating password guesses, without hashing them? Is it feasible to test against the plain-text password at password creation time and just check whether the word list and rules are going to generate a password guess that matches within some number of guesses?
Even better would be to perform the inverse operation of the rules to see if the test password would ever be generated by a ruleset, and get some non-naive measure of the password entropy given word lists and rules.
I own few sites too and one of them got hacked some time back. Luckily it was a new site so didn’t loose out on anything. I really don’t know what hackers are behind and even government don’t take much of action that quickly to stop these guys.
Whatever the security maybe still they can get hacked then no point of looking at it rather than making the system strong.
1 Like