sha-256 is not the best for passwords

also related

@Kepotx May 2011 - LastPass uses 100,000 iterations of SHA-256 (source: LastPass). I apologize if I'm misunderstanding you, but this is saying that 100k iterations of SHA256 is a good idea.

not SHA-256 alone but PKBDF2-SHA256

@CertifcateJunky Not only is that PBKDF2-SHA256 (or possibly PBKDF2-HMAC-SHA256, many people for some reason omit the HMAC when referring to it) rather than SHA256, it's also from 2011.

@AndrolGenhald so PBKDF2 is what I should be using

@CertifcateJunky Do yourself a favor and use bcrypt, or if you can't install packages at least use python's built-in implementation of PBKDF2. Also be aware that a pure python implementation will be slower (as noted in the docs), meaning an attacker has even more of an advantage.

And as for how many iterations in general, I heard that there's no direct raw answer, and some basic "metric" is to use "enough iterations so it will take 1-2seconds on a regular computer" (slow enough to stop brute force, fast enough to be UX friendly). This is the way KeePass 2 uses (see "Database settings", you'll have a "Use iterations so saving takes 1 second" button)

And as LastPass (and lot of others password manager) does, you can make it variable, so everyone can adapt his own number of iteration. For example, I've got a gaming computer with quite good graphic card, so I can do more iteration than someone with a less powerfull computer

Thank you for the advice guys, I'm going to go ahead and use Pythons PBKDF implementation, with enough rounds that it takes a couple seconds to hash it. Much appreciated.

@Xenos the end verdict, is that it will take TIME: 1.90619087219 seconds to hash the password

PBKDF2 is weak to ASIC/GPU attacks. If possible you should use Argon2, the winner of the "Password Hash Compeition" (used to look for a PBKDF2 replacement). Failing that, go with bcrypt, which is widely available.

@Kepotx Graphics cards do not accelerate a serial PBKDF2 implementation (i.e. the one that a defender will necessarily be using). A fast gaming computer will do more iterations in a single second because it has a fast CPU, not because it has a fast GPU.

@forest, but since they allow for running multiple serial PBKDF2 functions in parallel, it does overall speed up the process of brute-force guessing the password, right?

@CertifcateJunky, leaving aside the usual guidance which you already got, I'll just note that the code you present here seems incomplete: it doesn't show any calls to sha256_rounds, or define what the variables are supposed to be, or what the user input is, etc. This makes it quite hard to see what you're actually doing, and therefore, quite hard to comment on.

@ilkkachu I could post all the code if you wanted, it's a lot though lol

if any of you are curious I put it on Github, it is not anywhere near complete, but it will give you a better idea of what works with what. The link is under the UPDATE in my question, or right here

@CertifcateJunky I would like to point out that the way you overwrite the sqllite file is not inherently secure. Abstraction of hardware means when you seek(0) and re-write, it doesn't mean the same nand cells in your SSD or the same bits on your HDD are specifically being overwritten. It's possible they are, but it's far from guaranteed. Better I think than just deleting the file, but probably not enough to stop the NSA (or KGB or China...)

@Aaron I actually was thinking about that last night. I'm going to try it today and use my forensic software to see if I can pull it and look at it or not. Thank you for the advice

@CertifcateJunky There may be operating system specific ways to request block specific operations from the hardware, but it's always a crapshoot with nand depending on how the controller is implemented. Unfortunately then your software starts to become more and more OS and even hardware dependent.

@ilkkachu It does help with brute forcing, yes, since you can make each shader process one password guess at a time, and GPUs have a lot of shaders. Each "stream" will not be much faster than a CPU, but there will be far more running at once. In theory you could write a version of PBKDF2 that can be accelerated using a GPU, just by appending the shader number to the input password and running one on each shader, then XORing the final results at the end.

@CertifcateJunky Forensic software is often not able to recover it because it can only see on the logical level, not the physical level, but highly specialized custom firmware or forensic hardware might be able to.