5 ms·

> and then you have to protect that resource as well. That's what I want to avoid. I'm more afraid of some mathematical patterns I unintentionally get into my

by WHA8m 4y ago

> and then you have to protect that resource as well. That's what I want to avoid. I'm more afraid of some mathematical patterns I unintentionally get into my string that turns all of this useless. Not sure if I can obfuscate enough to break the pattern. That's basically the question.

LinuxBender 4y ago
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.
- pwg 4y ago
  > 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.
  - LinuxBender 4y 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.
    - pwg 4y 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/a83d38f412b4737e99bbef804a270c40 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.
      - 4y ago

by WHA8m 4y ago

LinuxBender 4y ago

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.

pwg 4y ago
> 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.
- LinuxBender 4y 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.
  - pwg 4y 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/a83d38f412b4737e99bbef804a270c40 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.
    - 4y ago