Comment by LinuxBender | Hacker News Reader

Comment by LinuxBender | Hacker News Reader

Parent Full thread

JTR and hashcat cover many hash brute-forcing patterns but I would bet money on neither of those ever cracking the above example if using more than a few words and if the hashing method used a combination of BCrypt+sha512crypt. Saying that I have no idea what algo's are used by virtual currency wallets. I believe there are still some standing payouts available to people that can crack some wallets that people lost the password to.

I will not however bet money on this protecting someones diary/journal unless it had the same protections as wallets. Are hardware diaries a thing? I guess one could learn an unused language to keep notes as a layer of obfuscation. Let's make Sumerian pictographs cool again. Or perhaps Elvish Sindarin.

If we attempt to compensate for every pattern used by JTR and hashcat then we end up with 450+ character passphrases that can't be memorized and we are back to using some application to store it and protect that application which I am not opposed to but I tried to give OP an answer that is a viable trade-off and that did not require storing the password. i.e. in the spirit of their question and methodology

For remote brute force with something like THC Hydra the above examples the account should be locked out long before anything comes close.

> JTR and hashcat cover many hash brute-forcing patterns but I would bet money on neither of those ever cracking the above example if using more than a few words

That would depend upon the hash being attacked, and the willingness of an attacker to apply money to the problem.

This 8 GPU cracking rig: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

Speeds along at, among others, 104.2 GH/s attacking Skype hashes, 200.1 GH/s attacking PostgreSQL's hashes, 414.4 GH/s attacking MySQL323 hashes (if those are even present in the wild anymore) and 334.0 GH/s attacking NTLM hashes. Two to Four hundred Giga hashes per second is a lot of trials, and one would necessarily need to had a number of words to make up for that performance.

> and if the hashing method used a combination of BCrypt+sha512crypt.

The 8GPU cluster states 105.7kH/s for bcrypt and 1168.6kH/s for sha512crypt. Fewer words would be needed to be secure /if/ those algorithms were used. But, as has been seen time and again, not all sites storing password hashes use the better hashes.

the willingness of an attacker to apply money to the problem.

I agree but I think the problem here is that hardware wallets don't give up their hashes easily so the attacker either knows a secret hardware backdoor in which case ciphers are entirely bypassed, or they know how to coax the hashes out of those devices. Has this become a thing? I know some of them are vulnerable to side channel attacks and some of them only use sha256 but I have not seen a simple way to extract the hashes, at least not in the forums I visit. There are a few really cheap hardware wallets that people have reverse engineered the firmware and worked backwards to extract pins but I think that is for specific models.

Is there a common attack vector that applies to all the hardware wallets to extract the hashes?

For hardware wallets, provided there are no backdoors/side channels/JTAG holes, they are probably safe from this rig.

But, the OP's original statement: "for your crypto wallet or personal notes/ diary" encompasses by far more than merely "hardware wallets". So the relative safety of hardware wallets as a minority subset is not overall indicative of the safety of your proposed method for all the other members of the majority of the set.

Very interesting conversation for me. Thank you! Specifically I want to encrypt a folder with VeraCrypt for my data.

Reply on news.ycombinator.com