So the question now is: for a given level of security, which of these interfaces is easier for *you* to operate quickly. Which type of passcode is easier for you memorize?
-
Show this thread
-
Alphanumeric has two hypothetical advantages. If you pick the password *truly at random* you can get more entropy (strength) from each alpha button press, so your password could be shorter. But those fewer keystrokes come at the cost of squinting at small keys.
1 reply 5 retweets 65 likesShow this thread -
But of course we all know that none of you are picking your alphanumeric passcode at random. You’re all using Kitty123.
13 replies 16 retweets 170 likesShow this thread -
(Crap now I have to change my passcode.)
7 replies 9 retweets 240 likesShow this thread -
In all seriousness, if you’re using the alphanumeric option to pick a *non-random* passcode (as most people do) then it’s much harder to tell how much password strength you’re getting. Some, a lot. Some less than they think.
6 replies 7 retweets 75 likesShow this thread -
In practice (given the apparent limitations of current iOS attacks) it’s probably fine to use an alphanumeric passcode. It may be very secure. The real question is whether it’s worth the hassle of using the non-numeric keypad.
8 replies 5 retweets 52 likesShow this thread -
So in summary: random (long) numeric passcodes may be a more ergonomic choice for a given security level, especially if you force yourself to memorize the thing over a week or two (even if that involves carrying a post-it during that time.) But do whatever works for you.
18 replies 13 retweets 97 likesShow this thread -
Replying to @matthew_d_green
Honestly, this is why I still prefer a (rooted) Android phone where you can set a long FDE passphrase and a simpler unlock passphrase. If you shut the thing down the key material is gone unless you can crack a long scrypted passphrase.
1 reply 0 retweets 3 likes -
Replying to @marcan42 @matthew_d_green
I understand the trade-offs Apple is making with their more complex security implementation (and Android is moving in that direction with file-based crypto) but I'd rather have a much simpler to analyze FDE approach.
2 replies 0 retweets 1 like -
Replying to @marcan42 @matthew_d_green
The problem with FDE iirc was that for the phone to operate, keys must be in memory (so that binaries can be decrypted). The file based approach allow cleartext keys for non-essential files to be wiped from memory when the device is locked and to be encrypted with the passcode*
1 reply 0 retweets 0 likes
The OS is not encrypted, so the phone can boot and you can make emergency calls. However, to unlock the data partition (and thus boot the rest of the Android framework including all your user data) you need to type in your passphrase. This is a trade-off I'm willing to make.
-
-
Replying to @marcan42 @matthew_d_green
Sure, but the key of the data partition is still in memory once you typed your passphrase at boot, right?
1 reply 0 retweets 0 likes -
Replying to @Taiki__San @matthew_d_green
Yes. Ideally you'd want *both* schemes at once, but Google seems to think they can get fine grained data partitioning right (they can't) and thus forgo proper passphrase-controlled FDE when they use file-based encryption instead.
1 reply 0 retweets 0 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.