Multiple Android problems

sjaffesjaffe Junior Member

I just installed 1Password on a new Android 5.1 tablet I just got. Previously, folks on the forums, including Agilebits staff said I wouldn't have any problems with running 1Password on this device and syncing it with my the vault on my Mac running Mavericks. However, I've found several problems using 1Password on the tablet:

  1. 1Password is constantly asking me for my password, even if just seconds have passed since I last entered it. This is a major annoyance, especially if I'm editing logins, changing settings, etc.
  2. I set up Automatic Filling and Manual filling as per the directions on this site. However, when I go to a web page with a login, the 1Password icon does not appear anywhere on the keyboard
  3. On my Mac, I can go to a dropdown list of all the logins, choose one, and 1Password will go to that site and enter my password and log me in. That functionality doesn't appear to exist on the tablet.

As far as I can tell, 1Password on the tablet doesn't seem to work at all. Yes, there's a vault there, synced with the Mac via Dropbox, but I can't seem to use it other than to look at the logins and edit the logins. I can't use it to enter the password on any website using either the automatic filling or the manual filling.

What am I doing wrong? Anyone got any help for me?

Thanks in advance.


1Password Version: 6.3.3
Extension Version: ????? no extension??
OS Version: Android 5.1
Sync Type: Dropbox
Referrer: kb:undefined, kb-search:different versions

Comments

  • periperi

    Team Member

    Hi @sjaffe. Sorry to hear you're having some trouble with 1Password on Android. I'll be happy to help out here.

    1Password is constantly asking me for my password, even if just seconds have passed since I last entered it. This is a major annoyance, especially if I'm editing logins, changing settings, etc.

    Does this happen when you're actively using 1Password, or if you tap away using the Home button, if the device display times out, or if you leave 1Password for some reason?

    Once unlocked, 1Password should stay unlocked while being used actively. However, if you have Lock on exit set to On, or if you have 1Password set to automatically lock after a short period of time, and if you don't have a PIN code enabled, then you will indeed be prompted for your Master Password if you leave the app or if the display times out. You can find more about the security settings surrounding this here:
    https://support.1password.com/guides/android/settings-security.html

    I set up Automatic Filling and Manual filling as per the directions on this site. However, when I go to a web page with a login, the 1Password icon does not appear anywhere on the keyboard

    Can you confirm that you switched to the 1Password keyboard after enabling it? You won't see the 1Password button on your default keyboard, so you'll need to make sure to switch your input method before the 1Password keyboard is active.

    On my Mac, I can go to a dropdown list of all the logins, choose one, and 1Password will go to that site and enter my password and log me in. That functionality doesn't appear to exist on the tablet.

    Due to the limitations of mobile browsers, the 1Password browser extension won't work on mobile platforms like it does on desktop platforms. Instead, you'll need to manually save Logins according to these instructions:
    Android - https://support.1password.com/guides/android/create-items.html

    For automatic filling on Android, you'll need to use the custom keyboard and accessibility service. However, there's also the option of filling in the 1Browser. To do so, just tap the URL you have saved with a Login item. This will open the URL in 1Password's built-in browser and fill your data for you.

  • periperi

    Team Member

    Thanks for getting back to me @sjaffe. With regards to the locking issue, that does indeed sound like expected behavior. When set to Lock on exit 1Password will indeed lock when switching between windows and any time that 1Password is moved to the background. Without a PIN code enabled, you will be prompted for the Master Password when returning to 1Password. This should be resolved after changing your security settings as you mentioned doing.

    As to filling, it sounds like you have enabled the 1Password keyboard, but haven't yet switched to it from your default keyboard. Android allows you to install and enable several input methods, and then it's up to you to select which one to use. Most devices have what is called a softkey which allows you to quickly choose keyboards. First tap into a text entry field to bring up the keyboard. Then (depending on your device), you should see a little keyboard icon appear in the notification bar at the top of the screen, or at the bottom right of the screen. Tap the icon (or swipe down from the notification bar) to change your input method, and select the 1Password keyboard. Then you should see the 1Password button for filling. You can find more instructions here:
    https://support.1password.com/android-keyboard/#use-the-1password-keyboard

    If you find you need to save a Login item from Android, I recommend doing so by following these instructions:
    https://support.1password.com/guides/android/create-login.html

    The 1Browser is a browser we built into 1Password. Just tap on a Login item, and from the item details view, tap the URL for that item. This will open the URL within the 1Browser and fill your data. If your data doesn't fill automatically, tap the key icon you see and it should fill. :)

    Please give those steps a try! That should help. :)

  • periperi

    Team Member

    Hey @sjaffe.

    I will not be using the PIN code. It is not as secure as Pattern Matching which is what I am using. Your software doesn't seem to support that

    To be clear, 1Password's PIN code unlock does not supersede your device's pattern unlock. You'll still use your pattern to unlock your device, and can then use the PIN code to unlock 1Password under certain conditions. Keep in mind that this does not replace the Master Password, and you're still required to enter the Master Password once 1Password has been exited from the background, or if the device is rebooted.

    We don't support pattern unlock, but I can certainly pass your interest in that along to the team.

    As to filling, it sounds like you were indeed able to switch to the 1Password keyboard. 1Password's accessibility service searches for login fields in an app or on a website. If login fields are detected, the 1Password button will turn blue to indicate that automatic filling is available on the page. If 1Password doesn't detect login fields, then the 1Password button will remain gray indicating that you'll need to manually fill. When you see "Fill username" and "Fill password" this means that automatic filling isn't available for the page you're on, which is why you need to tap into the username field, fill the username, and tap into the password field and fill the password.

    The reason for this is that we would never want to automatically enter your data into any random, insecure field. If 1Password detect login fields and know where to put your data on the page it does. But if it doesn't know where to put your data, it will require you to specify where it goes, Without this, your data could potentially be automatically filled into any random field. Say for instance you were on the Facebook page and tapped the 1Password button and tapped your Facebook Login. We would never want to fill your Facebook username and password into the status field on that page.

    Further to this, automatic filling isn't possible when using Firefox, and some other browsers, as they obfuscate URLs which prevents 1Password from detecting what page you're on. Chrome doesn't have this issue, though, so if you're using Chrome you should be able to automatically fill.

    The locking issue you're having definitely sounds abnormal. If you have Lock on exit set to off, 1Password shouldn't lock until the auto-lock timer runs out. Can you verify that you have Lock on exit off, and check the auto-lock time, then tap the three dots in the top right corner and then tap Exit. Then relaunch 1Password. Are your security settings working now?

  • periperi

    Team Member

    You won't have to type the PIN code and the Master Password. With a PIN code enabled, you'll be prompted for the PIN any time you go back to 1Password after moving it to the background. As long as 1Password stays running in the background, you'll be prompted for the PIN. However, if you fully exit 1Password from the background, either by tapping Exit from the overflow menu, swiping to close from your recents list, or rebooting your device, you'll be prompted for the Master Password again. Once the Master Password has been entered again, you'll be prompted for the PIN again when you switch away and then back to the app.

    As to brute force attacks, 1Password uses an exceedingly secure encryption algorithm. In addition, we slow unlock attempts so that if someone were to try to guess your Master Password, they would be slowed after each failed attempt to login. Someone trying to guess your Master Password therefore would have to wait minutes, days, or weeks to enter a new guess after a number of failed attempts. You can find more about it here:
    https://support.1password.com/secure-by-design/

    That said, your vault is encrypted with the Master Password and can only be decrypted with that Master Password. Your PIN code is only used to unlock your vault while the app is open in the background and your encryption key is already stored in memory. This is why you need to enter the Master Password again after fully exiting and relaunching the app.

    1Password does indeed support Fingerprint Unlock, but it does not replace the Master Password either. You can find a description of how Fingerprint Unlock works on Android here if you're curious:
    https://discussions.agilebits.com/discussion/comment/272225/#Comment_272225

    As for the locking issue: Lock on exit is set to "off", the auto-lock timer is set to "never". I exit 1Password, then start it again, and I am asked for the Master Password.

    If you are prompted for the Master Password after fully exiting the app, that's expected as you'll now need to decrypt your vault with the Master Password. However, after entering the Master Password, if you tap away using the Home button and bring 1Password back up, is it still unlocked?

  • @sjaffe

    FWIW, PIN codes and Master Passwords can be cracked far more easily via brute force methods than a pattern match such as fingerprint or the basic pattern match that Android used pre-6.0.

    That seemed a bit unlikely to me, particularly with respect to cracking a master password, so I did a little digging, and found an article on ArsTechnica which points out the limitations on pattern matching.

    While it's true that a grid of 9 points can result in up to 140,704 possible patterns, humans are predictable, so most people don't randomly choose their pattern. That makes it far easier to potentially crack a pattern, and that's without even getting into issues such as how much easier it is to shoulder-surf a pattern, or the streaks on your screen potentially betraying your pattern.

    In contrast, a randomly selected 5-digit pin has 10^5 or 100,000 possible combinations, and IMO would be far more secure. If you use a six digit pin, there are 1,000,000 possible combinations, which is clearly superior.

    Passwords, of course, can be far more complex than this. A relatively simple 4-word diceware password that draws on the standard list of 7776 short words has 7776^4 possible combinations, or 3,656,158,440,062,976 combinations. Or, if you prefer, a 9-character password that randomly uses only the symbols available on a standard US or Western keyboard has even more possible combinations.

    The FBI certainly admitted to that during the hoopla surrounding the fight with Apple.

    I'd be interested in any references you could provide related to this statement, or any other thoughts you have about why pattern matching isn't as weak as I think it is.

  • brentybrenty

    Team Member

    @EnerJi: Wow. Fantastic! Thanks for sharing that! Indeed, humans are infamously (genetically?) incapable of creating — or memorizing — random patterns, so that will be the deciding factor when it comes to the strength of any passcode: how it was created. I wonder if there's a random "pattern-type" generator out there though. That would be an improvement!

    @sjaffe: Re: FBI v. Apple, they were "lucky" in that the device they were attacking (iPhone 5C) predated the hardware security built into later models. it's believed that the reliance on software to enforce brute force protections was ultimately the key.

  • brentybrenty

    Team Member

    Given enough time, a computer can be programmed to go through all the possible combinations to crack a password.

    @sjaffe: You've left out "computing power" and "energy", both of which are critical to being able to brute force anything within a timeframe that's relevant to humans.

    The number of possibilities are irrelevant if you're picking the pattern yourself. And 1Password uses PBKDF2 to slow the number of attempts significantly as well. There are a lot of factors to consider.

  • @sjaffe

    People picking non-random passwords is a big problem. Fortunately, 1Password supports and encourages solutions to that problem with their password generator, and helpful blog posts such as in the article below. There's likely to be far less visibility or understanding in how to choose a truly random pattern.

    https://blog.agilebits.com/2011/06/21/toward-better-master-passwords/

    In addition, I'm not sure you realize just how time consuming it can be to crack a sufficiently complex password. Take a look at this blog post from three years ago:

    https://blog.agilebits.com/2013/04/16/1password-hashcat-strong-master-passwords/

    Back then, using the older Agile Keychain format and a state-of-the-art GPU cracking machine, a 52-entropy-bit password would take a minimum of 193 years and as much as 867 years to crack, running full-time, 24x7. Since then, 1Password uses a newer encryption format with improved key stretching, which further slows password cracking attempts.

    At the same time, computers are now faster, which offsets the improved key stretching, and continue to get faster every year, so it might be prudent to use an even more secure password in order to protect your vault. A 65-bit-entropy password is not likely to be crackable for many years, outside of nation state capabilities, and if your data was of sufficient interest to them, they could easily resort to rubber hose cryptanalysis, as depicted somewhat amusingly (or chillingly, depending on your perspective) in this xkcd comic:

    Finally, all of the above is moot when you consider that by using a pattern lock, you are most likely not encrypting your tablet, which makes it trivially easy to bypass your pattern lock simply by connecting your tablet to a computer with the appropriate software tools installed.

    Bottom line: your posts prompted me to look into this in more detail to confirm my own suspicion, and I am more convinced than ever that a pattern lock is a simply terrible idea if you care a great deal about security, and is either way, far inferior to a complex and randomly chosen password.

  • @sjaffe

    [Since you don't seem to want to continue the discussion I hesitated to respond, but I want to make sure that anyone who comes across this thread doesn't get any wrong ideas.]

    You said a lot of experts recommend a pattern lock - I'm sure many do, as it's better than having no password at all.

    Aside from that, while sufficiently complex passwords may take years to crack, most people don't use them which is why cracking tools are so prevalent. If you really want to understand the problem, read some books on cryptography and computer security.

    I'm well aware, which is the reason I use 1Password in the first place. No secondary reading required for me on this one. ;)

    But, part of the problem that you forget is that sufficiently complex passwords that are that difficult to break by computer are also difficult, perhaps even impossible, for the ordinary person to remember. And since this subject is about unlocking the device, you can't rely on 1Password to provide the password - you have to remember it. When the average person is creating a password that they can remember, it's not going to be all that complex and you're not talking about years to crack, you're talking about hours.

    I agree with the first two sentences, but not necessarily with the third. That's why I linked a 1Password blog post related to diceware passwords - passwords which are relatively easy to remember, yet comparatively fairly secure. Nevertheless, I concede it is quite a burden to use a long password on a mobile device without relying on features to reduce the number of times you need to input the password, such as a fingerprint reader and trusted bluetooth device pairings.

    Patterns cannot be brute-forced by computer. Period.

    I beg to disagree. The pattern gesture is converted by Android to a number, which is then hashed. It's absolutely possible to brute force it, and here's some sample code if you don't believe me:

    https://gist.github.com/danzek/f9416b1404570754b10f

    By the way, I'm not impugning the potential benefits of other pattern-based security schemes (I am not qualified or well-read on them to have much of an opinion.) I am specifically calling out Android's gesture pattern unlock scheme as inherently insecure. Beyond the cracking code above, you didn't address this very important part of my last post:

    Finally, all of the above is moot when you consider that by using a pattern lock, you are most likely not encrypting your tablet, which makes it trivially easy to bypass your pattern lock simply by connecting your tablet to a computer with the appropriate software tools installed.

    At the end of the day, what this all comes down to is the threat level you are trying to protect against. Casual snooping by a guest or colleague would be deterred by a pattern lock about as well as a moderately weak password (just don't use your kid's or dog's name).

    But if you're trying to protect against a modestly technical attacker who can get short-term physical access to your device, Android's gesture pattern lock is not the way to go. For one thing, Android doesn't support full device encryption (FDE) with a gesture-based pattern lock. Therefore, in the time it takes you to go to the kitchen to make a coffee, an attacker could copy the contents of your device for their later perusal.

    On the other hand, if you're trying to protect against an attacker accessing your data from a stolen or lost tablet, a gesture pattern lock is an even worse idea. Beyond the ability to crack gestures (see above), based on what I've read, it's trivially easy to non-destructively disable the pattern lock on an unencrypted Android device. Simply download the free adb tool which is part of the Android SDK, plug the phone into a laptop, and run a few commands. Presto, unlocked phone/tablet.

  • brentybrenty

    Team Member
    edited July 2016

    If pattern lock is a terrible idea, then why do so many experts recommend it? And, remember, fingerprint is a pattern lock.

    @sjaffe: "Pattern lock" isn't the terrible thing; human-generated passcode is. As far as I know, we don't have the technology to generate our own fingerprints. They're very much unique and, to a computer or human, appear random. And the implementation matters (see below, and the previous post).

    Aside from that, while sufficiently complex passwords may take years to crack, most people don't use them which is why cracking tools are so prevalent. If you really want to understand the problem, read some books on cryptography and computer security. But, part of the problem that you forget is that sufficiently complex passwords that are that difficult to break by computer are also difficult, perhaps even impossible, for the ordinary person to remember. And since this subject is about unlocking the device, you can't rely on 1Password to provide the password - you have to remember it. When the average person is creating a password that they can remember, it's not going to be all that complex and you're not talking about years to crack, you're talking about hours.

    You make some excellent points. It's absolutely necessary to be able to remember the password. But with things like 1Password's Wordlist and Diceware™, there are good options. And I'm sorry if I wasn't specific enough, but it isn't as simple as performing a quick brute force attack against your Master Password. If it were, you'd be right, but PBKDF2 and other memory-hard hashing methods make it exponentially more difficult to perform the attack you're imagining.

    If it takes only hours to brute force your vault, you didn't even try to come up with a reasonably strong password. And if it were possible to crack AES256 as you presume, we'd all have much bigger problems than our Master Passwords, as everything in the industry depends on it. It isn't currently feasible on a human timescale. And if and when it becomes feasible, it will be huge news and none of us will miss it — should we live to see that day.

    Finally, don't be fooled by what seems to be intuitive, or what seems to be so complex as to be unbreakable. My favorite story on that is what happened at a conference some 15 or so years ago. Are you familiar with Kerberos? It uses one-way hashing of passwords which is supposed to be unbreakable. Supposedly, at a conference where the 128-bit Kerberos was announced, they had the designers talking about how it was unbeatable. By the end of their lecture, two mathematicians in the back of the room announced that they had cracked already cracked it. Apocryphal story or not, it's clear that that any method that relies on the number of possible combinations being so large, or so complex, as to make it impossible to break is probably breakable.

    You're right! New, untested "security" products and processes are invented every day, and many are summarily defeated or bypassed. AES has withstood the test of time, and many Black Hat conferences. People don't generally attack AES anymore; they try to find flaws in people's new "creative" implementations of it, because that's where the juicy stuff lies.

    I'm done arguing about this subject. Many of the experts that I've looked at recommend pattern match (such as fingerprint) over passwords. As far as I'm concerned, they will always be more secure than password/PINs because a computer cannot be programmed to brute force try every possible combination. Patterns cannot be brute-forced by computer. Period. That alone makes them more secure, regardless of how long it might take to break a alphanumeric password. Alphanumeric passwords can be cracked, patterns cannot. It's as simple as that.

    Ultimately it doesn't matter. If you don't believe that encryption is secure, I'm not going to convince you. And were I in that position, I can't imagine trusting my secrets to any security software — including TLS, AES, Android, iOS, etc. — because they all depend on it.

    The pattern gesture is converted by Android to a number, which is then hashed. It's absolutely possible to brute force it, and here's some sample code if you don't believe me: https://gist.github.com/danzek/f9416b1404570754b10f

    You make a good point. No brute force attempt is going to involve a prosthetic finger fondling a phone screen. :lol:

    But if you're trying to protect against a modestly technical attacker who can get short-term physical access to your device, Android's gesture pattern lock is not the way to go. For one thing, Android doesn't support full device encryption (FDE) with a gesture-based pattern lock. Therefore, in the time it takes you to go to the kitchen to make a coffee, an attacker could copy the contents of your device for their later perusal.

    You're absolutely right: device encryption is crucial, unless the only things we have of value reside behind 1Password's separate vault encryption. I'm sorry to say that it's something I take for granted now, but not all devices — or setups — support full-disk encryption. :(

  • @sjaffe

    As I said, I'm not going to go on with this pointless argument with you both. You want to believe what you want to believe and nothing seems to be able to change that.

    Unfortunately, I feel the same way. You don't seem to be addressing any of the substance of what I wrote. I'll just reiterate what I wrote previously:

    By the way, I'm not impugning the potential benefits of other pattern-based security schemes (I am not qualified or well-read on them to have much of an opinion.) I am specifically calling out Android's gesture pattern unlock scheme as inherently insecure.

    I stand by that. You can believe your supposed "NSA/FBI/law enforcement experts" that you have consulted, but I think you might have misconstrued or misinterpreted what they may have said.

    I haven't posted links to any sites which might be considered a bit unsavory out of respect for 1Password's forum, but if you do a simple Google search for "bypass Android pattern" (with the quotation marks), you'll find multiple sites on the first page with simple instructions on how trivially easy it is to bypass the Android lock screen gesture pattern.

    Anyway, good luck to you.

  • DanielPDanielP

    Team Member
    edited July 2016

    Hi @sjaffe

    Sorry for the intrusion, but when I see something Security I light up :)

    Many of the experts that I've looked at recommend pattern match (such as fingerprint) over passwords. As far as I'm concerned, they will always be more secure than password/PINs because a computer cannot be programmed to brute force try every possible combination. Patterns cannot be brute-forced by computer. Period. That alone makes them more secure, regardless of how long it might take to break a alphanumeric password.

    I am honestly interested in this. Do you have some resources to point me to that support this claim? It was my understanding, as also mentioned in a previous post by @EnerJi , that it was indeed possible to crack patterns (ultimately, gestures are encoded to integers, so it shouldn't be much different to perform a brute-force attack against them, with the added benefit of only having to deal with integers and not with alphanumeric characters).

    According to the article at https://quora.com/Android-operating-system-How-many-combinations-does-Android-9-point-unlock-have there are nearly 390K combinations for the Android 9-point grid.

    If my approach is correct, the exact number should be 362.880 in the best case scenario (i.e. a 9-point pattern in a 3x3 grid). In this case, the number should simply be 9 factorial (9!) (anybody please correct me if I am wrong).

    This though, would be the best case scenario. If you are using a shorter pattern, the number would change quite dramatically. In the worst case scenario (i.e. a dumb 1-point pattern on a 3x3 grid), the result would be simply 9.

    Of course Android requires you to follow some security precautions (I think the pattern should have at least length 3) so this is just an example.

    Please feel free to correct me if I am wrong, but I believe what @EnerJi and @brenty were trying to say was that PINs are mathematically more secure than patterns. On paper, a 9-digit PIN has 10^9 possible combinations, which is a much higher number thatn 300K+ coming out of a 9-point pattern.

    And your argument about predictableness of selecting the pattern is meaningless because the same argument goes for passwords - research has shown that most people pick predictable passwords and PINs. We have a longer history and more data involving people's picks for passwords and PINs than we do for picking patterns so the argument that patterns are more predictable is a somewhat weak argument..

    I agree with this. The same objection could be made to the pattern argument. To be thorough, perhaps patterns are even more at risk here, as some combinations are physically more difficult to achieve (I am thinking about patterns going from 1 to 3, skipping 2, or a pattern going from a 2 to a 9, you get the idea). If we factor this in our calculations, the number above would become even smaller.

    Of course, all of this would indeed become useless thinking should patterns be indeed not crackable, but still it's fun to discuss :)

    Just my two cents. There are many other considerations we could make (smudge analysis attacks is one that comes to mind, or the switch to passphrases from passwords, changing passwords at regular intervals to counter brute force attacks...).

    Ultimately, both methods (and I think you are all agreeing on this) are just as secure as the user decides them to be. Crackable or not, 1234 and an equivalently complex pattern would not help much anyway.

  • EnerJiEnerJi
    edited July 2016

    Hi @DanielP, thanks for weighing in.

    If my approach is correct, the exact number should be 362.880 in the best case scenario (i.e. a 9-point pattern in a 3x3 grid). In this case, the number should simply be 9 factorial (9!) (anybody please correct me if I am wrong).

    I think the number of permutations is actually higher than 9 factorial, but is reduced by the Android requirements related to number of points, not hopping over points, etc. I tested this out by drawing a 3-point grid, and imagining all the different combinations of at least two points. I stopped counting when I saw it would clearly be much higher than 3! (6).

    The Ars article I linked to earlier in the thread (which I accidentally misquoted above in the thread) comes up with 389k+ combinations, with the limitation that Android requires at least four nodes to be included (and presumably contiguously, although I've not verified this.)

    Ultimately, both methods (and I think you are all agreeing on this) are just as secure as the user decides them to be. Crackable or not, 1234 and an equivalently complex pattern would not help much anyway.

    I would personally say that both methods can theoretically be made as insecure as the user decides (as there is a very real upper bound on how complex the Android pattern lock can be). However, this also assumes that the pattern lock can not be bypassed, which it almost certainly can on an unencrypted device.

    I do also think smudge analysis is also a very real threat to a phone/tablet screen pattern lock (even if for nothing more than reducing the possible combinations of patterns which are likely to have been used.)

  • DanielPDanielP

    Team Member
    edited July 2016

    @EnerJi thanks for the reply :) Your post made me realize two mistakes I made in my previous post, the first one being that I really meant a 3x3 grid (not 9x9) so post edited ;) (I also took the liberty to edit your quote as well for future clarity, hope you don't mind).

    Second, the number 9 in the factorial comes from the number of dots in the grid, not the length of the pattern. Your calculations for a pattern of length 3 where correct, the formula wasn't :)

    And this is what made me realize my second mistake: if you simply use 9 factorial, you are not taking into considerations the actual length of the unlock pattern, which is one of the important variables to determine the complexity of the pattern, of course.

    So this looks much better: x! / (x-n)!, with x the number of points in the grid and n the length of the pattern.

    This seems to work. Let's take a simple 2x2 grid for example, and a pattern length of 2. If we substitute these values in the formula above we get 4! / 2!, which correctly returns 12 as the result (this is easy to prove as there are only 6 possible ways to connect the dots, 12 if you factor in bidirectionality).

    In any case, we are still talking about less than 400K possible combinations in a 3x3 grid (and, as you correctly pointed out, likely way less than that due to pattern limitations in Android), which is still way less than the 10^9 possible combinations you would have using a 9-digit PIN, so still, on paper, PINs are more secure than patterns. In the real world it might not be so, I am waiting for some more evidence on this as I am really interested to find out something more.

    I would personally say that both methods can theoretically be made as insecure as the user decides (as there is a very real upper bound on how complex the Android pattern lock can be).

    Agreed :)

  • @DanielP

    So this looks much better: x! / (x-n)!, with x the number of points in the grid and n the length of the pattern.

    This seems to work. Let's take a simple 2x2 grid for example, and a pattern length of 2. If we substitute these values in the formula above we get 4! / 2!, which correctly returns 12 as the result (this is easy to prove as there are only 6 possible ways to connect the dots, 12 if you factor in bidirectionality).

    Interesting. So if I'm following this properly, to calculate the total number of supported Android lock patterns, assuming a 3x3 grid (9 points) with a minimum pattern length of 4, we would have:

    (9! / (9-4)!) + (9! / (9-5)!) + (9! / 9-6)!) ... (9! / (9-9)!) which equals only 18,730, if my math is correct? That "feels" low and is dramatically lower than the number I've seen posted on security blogs, but perhaps I missed something.

    I did come across this Quora response where there's some fairly vigorous debate on the finer points of Android's pattern match requirements and whether it's even possible to calculate it cleanly or whether the number of permutations has to be brute forced. It's a bit beyond my level of interest at this point, but I include it here in case anyone wants to geek out. :)

  • DanielPDanielP

    Team Member

    @EnerJi

    Correct, that should cover all possible combinations for each allowed length of the pattern. With some help from Wolframalpha, the sum of all factorials gives 985.824 possible combinations ((9! / (9-4)!) + (9! / (9-5)!) + (9! / (9-6)!) + (9! / (9-7)!) + (9! / (9-8)!) + (9! / (9-9)!)), for a pattern of length between 4 and 9 included, which is bigger than the number you got but still quite small at the end of the day.

    This is a likely optimistic number though: can you even go from a 1 to a 3 for example, while skipping the 2? Just one question I am not sure the answer to is "yes". So the problems seems to be quite complex, you would have to consider adjacency as well. I will leave this to someone else to come up with an exact number though :P

    The article you've linked to is also pretty interesting and would also suggest that the effective number of possible combinations can be much lower than that. It's a pity that they haven't added some sources to back up some of their claims though (for example, stating that the average length of the pattern is 5, or that being left- or right-handed doesn't seem to influence this as much).

    To make things easier, perhaps we can talk about orders of magnitude. Even considering slight differences in the final number of possible pattern combinations, a pattern must be longer than a PIN to achieve the same number of combinations, which in itself is quite interesting to think about.

  • @DanielP I used Google's calculator for the calculations, but must have messed up somewhere. Your number sounds much more reasonable, although as you said, the "true" number is undoubtedly smaller due to a pretty significant number of impossible moves.

    All this is somewhat academic, however, as absent any authoritative sources to the contrary, I firmly believe using an Android pattern lock is significantly inferior to using a six-digit or greater PIN/password.

    On a related topic, it appears that Apple is continuing to improve the security of its devices - it will be interesting to see if Google feels the pressure to follow suit.

  • DanielPDanielP

    Team Member

    @EnerJi I agree with you. I'll be more than happy to read some extra documentation about this when it becomes available though. Myself, I will keep using fingerprints whenever possible ;)

  • @DanielP Same here!

  • DanielPDanielP

    Team Member

    Interesting discussion however, if anybody has anything to add, we are all ears :)

This discussion has been closed.