tl/dr: This method hurts your password strength quite a lot due to the loss of characters (mainly since 0 and 1 are often left out when
entering letters through a numeric pinpad). However, trying to brute
force a password here is slow, so with a long enough password you'll
be fine anyway.
You already seem to know the answer, but I'll spell it out with a bit more detail in hopes that this is helpful.
Unfortunately, your selected method of password generation will, quite possibly, generate the lowest possible amount of entropy. Obviously you would get less entropy by picking a clearly bad password, but this method still gives pretty poor results.
The best way to see this is by comparing against it's entropy ceiling - a pure digit password. That's a simple one. If all you have is numbers then you have
10^n possibile passwords, where
n is the number of digits in your password. A 4 digit password has 10,000 possible combinations, etc...
In your case though your numbers are determined by conversion from letters. As you know, the English language doesn't use letters evenly, resulting in a loss of entropy. It would be difficult to determine exactly how much entropy is lost, so a good paper would be required. I don't have one of those though, but I can still guestimate!
- You lose at least 1 number because in most letter mapping systems the 0 is unused
- Many telephone keypads leave the 1 unused as well
- And of course the variation in frequency hurts. Harder to estimate so I'll just knock off another digit and call it a day
You'll effectively lose 2-3 possible characters out of the 10 you have. This actually takes a big hit out of your entropy, because the number of possible passwords is determined by
[Number of characters]^[Password Length]. The presence of that exponent makes this very non-linear, as we'll see below.
Is this a deal breaker though? That depends!
Deciding how difficult a password is to crack depends on two things: the number of possible passwords, and the rate at which an attacker can guess passwords. Both can be determined accurately enough in this case. First, how many possible passwords are there? Let's assume you end up with a 12 character password, and let's compare against three passwords: randomly chosen numbers and characters, randomly chosen numbers, and random numbers without 0 and 1.
We also need to know how fast an attacker can run through passwords. Just for kicks, I'm going to compare two speeds: the rate at which a high-end GPU hashing rig can crack MD5 hashes (200GH/s), and the rate at which a very experienced person can enter numbers into a pinpad. Obviously the former (the MD5 hashing rig) is not in the least bit applicable here, but I want to include it because I think it will give a helpful reference. For pinpad entry, it's hard to guess exactly how fast an attacker can enter passwords, but we'll be generous and give them 10 guesses per second. Here are our numbers:
- 12 character alpha numeric password. Number of possible passwords:
62^12 = 3e21 (entropy =
log2(3e21) = 71 bits of entropy)
- 12 character numeric password. Number of possible passwords:
10^12 = 1e12 (entropy =
log2(1e12) = 39 bits of entropy
- 12 character numeric password (but without 1 and 0). Number of possible passwords:
8^12 = 6.9e10 (entropy =
log2(6.9e10) = 36 bits of entropy.
Against a cracking rig
Our cracking rig can check 200,000,000,000 (aka
2e11) passwords per second. Simply divide the number of passwords by the hashing rate to get how long it will take to crack it:
- Alpha numeric:
3e21/2e11 = 1e10 seconds = 511 years
- All numbers:
1e12/2e11 = 5 seconds
- Numbers without 1 & 0:
6.9e10/2e11 = 0.3 seconds
As you can see, there is a huge difference in their cracking times. For reference, some websites still use plain MD5 for storing passwords, so the above math is why using a long, random password is required. Of course an attacker can't just hook your wallet up to a GPU cracking rig and run through guesses that quickly.
Instead the passwords have to be entered by hand, so we'll try again with our 10 passwords per second rate (which is probably very generous):
3e21/10 = 3e20 seconds = ~700 times the age of the universe
- All digits:
1e12/10 = 1e11 seconds = ~30 centuries
- Numbers without 1 & 0:
6.9e10/10 = 6.9e9 seconds = 2 centuries
Your password is still quite uncrackable under these circumstances, but it is worth noting that losing just 2 out of 10 possible characters reduced the cracking time by a factor of 15!
The above analysis assumes a full brute-force search of the entire password space. For a long diceware-style password that is actually quite unrealistic, and an attacker would be better off working off of the actual word list. In that case, a more detailed analysis from the OP shows that the loss of entropy is much smaller. Either way though the overall summary remains the same:
So your chosen method definitely weakens the password. However, given that these passwords have to be manually entered (and therefore password cracking is quite slow), you can still get sufficiently secure passwords even with this method, as long as it is long enough.
Personally though, since we're talking about a potentially high-value target that someone has to physically steal, I'd be more worried about rubber-hose cryptanalysis.