undefined | Better HN

0 pointsLinuxBender3y ago0 comments

I could suggest a few simpler ideas that are highly unlikely to be brute forced. Actually I will keep it simple and suggest one.

Multi-Words with Character Padding:

- Pick 2 to 5 words. The more sensitive the thing, the more words. The words I am providing are simple and common. Pick less common words you can remember.

- Pick a padding character. e.g. %

If using 2 words "battery" and "horse" then pad with 2 characters. The password becomes %%battery%%horse%%. That is probably sufficient for low risk assets. Higher risk? "battery", "horse", "banana", "hogsmead" becomes %%%%battery%%%%horse%%%%banana%%%%hogsmead%%%%.

If that pattern is too easy to remember then also remember based on the number of words which character to capitalize. 4 words = 4th letter capitalized. %%%%batTery%%%%horSe%%%%banAna%%%%hogSmead%%%%. For memory sake, one could even create a sentence based on a service. "the chalice in the palace has my bitcoin" Now pad that for an astronomically difficult to brute-force password.

There are many other derivations of this concept only limited to ones imagination and long term memory. This method is easy for me to remember but you may find a different pattern more memory friendly.

0 comments

3 comments · 1 top-level

pwg3y ago· 2 in thread

> If using 2 words "battery" and "horse" then pad with 2 characters. The password becomes %%battery%%horse%%

This method is not at all safe, JackTheRipper and other password crackers already have patterns that include "combine two works with separator X" for brute forcing hashes. These patterns are trivial to automate for the cracking tools.

LinuxBenderOP3y ago

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.

pwg3y ago

> 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.

1 more reply

j / k navigate · click thread line to collapse