Hi, Brian wrote: > the crackers would likely not be in possession of a leaked password > (Uld4dFpYSkdkV1J3ZFdOclpYSUsK) but of a hash of it.
That's why i did not claim to be able to decipher such things but rather mentioned that the name is celebrity enough to be quickly enumerated. The next two secrets were: base64 once, which is rather normal, and then another base64 which would be guessable by a list of obvious obfuscation opportunities. Together this would be vulnerable to self-learning attacks which follow the habits and typical ideas of certain groups of people. > The password does not contain any memorable words so word lists do not > look an inviting prospect. This is not the decisive point. The list with celebrity names is input to the not extremely unlikely operation of double base64. After this chain of processing, you have a string that looks garbled, but is still based only on the thin secrets. > With the much slower bcrypt the effort to crack anything more might > have been too much. More bits and a more complex algorithm make testing slower, indeed. The mathematical bet is that there are no shortcuts to the slowliness. A secret salt (or other encryption key) may help if it can be kept completely separate from the hash list, so that the attacker needs two separate thefts. But from https://en.wikipedia.org/wiki/Bcrypt i understand the salt is stored unencrypted in the shadow password. So only the extra bits of the result and the hopefully reliable artificial slowliness of the algorithm can be counted as advantage over MD5. > Gene Heskett's password does not have all the criteria for being complex > and completely random, but for now it looks like it would escape > unscathed from brute force probing. If the attacker has a bcrypt shadow password then the same number of enumeration tries is necessary as with MD5. But it lasts linearly longer to test them. The linear factor depends on the "cost" parameter of the bcrypted password. In the wikipedia example it is 1024 times the cost of a single bcrypt round divided by the cost of a MD5 computation. I failed up to now with finding an estimation of this fundamental ratio. bcrypt seems to have indeed a good reputation. But google finds "Argon2" when i ask for "bcrypt successor". > Suppose > echo "ElmerFudpucker" | base64 | base64 > became > echo "ElmerFudpucker" | <some_bcrypt_processing> | base64 | base64 The latter is less secret than echo "ElmerFudpucker" | base64 | base64 | <some_bcrypt_processing> because as you could see with Gene's challenge, an unobfuscated base64 string is an invitation to run base64 -d. If the last step in the chain is bcrypt, then i have to guess about base64 | base64 md5sum | base64 sha512sum | base64 md5sum | xxd ... as many as Gene or i can imagine (but not many enough) ---------------------------------------------------------------------------- Whatever, it seems to me that you can really create extra security on your local side if you put that slow thing into the enumeration chain. Even assumed that your attacker knows it, he still has the problem that bcrypt weights on the enumeration regardless how poor the remote hash obfuscation is. (It must not be so poor that a collision easily lets him in although he tried a wrong password.) A very good property is that the whole bcryptization does not have to be secret and thus you may store its lengthy parameters in unsecure places. You will not use more than the hash part of bcrypt as password. No need to send "cost" or "salt" to the remote service. Assume that everybody knows them and thus you don't need to tell. :)) But still your brain password needs to be strong enough to become really strong by the added bits equivalent of bcrypt slowliness. If in the time of one bcrypt try one could do 4096 MD5s, then this bcrypt is worth 12 bits of secret, compared to MD5 and in the context of enumeration. The rest of hard-to-guess bits must be stored in your brain. I wonder whether one can arbitrarily increase the computation time by arbitrary high cost value without creating opportunities for a shortcut. Somehow this smells like information out of deterministic nothing ... ... the 184 bit hash must produce collisions after at most 2 exp 184 tries. So a wrong brain password would yield the right long password. This is a trivial upper bit count limit for what bcrypt can gain you. Probably the real systematic limit is lower. Young mathematicians needed. In any case you would buy a new bit by doubling password computation time for each time you want to use the password. So there are real world limits much lower than the bit count of the hash. The ratio of the attacker's computing power and your computing power matters. This is a disadvantage compared to other methods which harden against enumeration. Disclaimer: This looks quite good to me but might be wrong, nevertheless. All depends on whether bcrypt really has the properties which are intended. Not to speak of my questionable conclusions or of any non-enumeration strategies. Gene Heskett wrote: > Theodore T'so opinion IMO, carry's enough weight to more than "balance > the scales" in most any argument about this... Theodore was smack in > the middle of TPTB It is astounding how many people can tell such things about him. We all trust him daily, because you can hardly avoid to use his work if you run GNU/Linux. Have a nice day :) Thomas
