Ask HN: Would you consider a password like this safe?
The question is in the title. What password I mean in the following. Think of the required security as for your crypto wallet or personal notes/ diary.
I imagine an algorythm that gives out a password. The algorythm consists of a few rules that involve only information that I can access in almost every other houshold.
- calculator (basic arithmetic operations, cos, tan, sin, pi, e, ln, log)
- bibel (most names/chapters will be written exactly same in different translations)
- calendar (names and amount of days of months)
- clock/ watch
- periodic system
- personal data (birthdate, name of family members)
- alphabet
- chess board
- data I remember word by word (for example: dates/ events from history)
- The password has 16 figures.
- I multiply my birth year with pi.
- If a number is 1-5, I make a pair with its subsequent number.
- The first number of a pair specifys the book of Moses.
- Second number specifys the letter within the books name.
- If the second number is uneven, the letter is capitalized.
-> If I am born in 1990, password would be 6US69u06M688tEt0
14 comments
[ 3.7 ms ] story [ 36.3 ms ] threadThat'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.
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.
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.
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.
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.
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?
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.
If you want a safe password, then select the characters at random, and store the results in a secure location.
The method is obviously flawed as everyone born in 1990 shares this password. This one result though was relatively safe in that random password guessers estimate that it would take billions of years to crack.
Edit/ Addition: Can you share the tool you used to estimated the time? I knew there is a way to see how random something is, but search results are cluttered with generators and I couldn't find something.