> Our study found there is little benefit to longer 6-digit PINs as compared to 4-digit PINs.
as a basic rule of thumb, any paper on cybersecurity that does not start the discussion with a reference attack vector and listed assumptions is probably garbage.
a charitable interpretation would be that they left out such details in the leading summary, but those details matter more than the actual findings. if im an IT manager and trying to decide how to lock phones, an accurate threat model is more important than the mitigations. good mitigations against the wrong threat is much, much worse than bad mitigations against the correct threat
EDIT: woops! i did the bad thing thats ruining society and read the web article instead of the paper. the paper has a whole section on picking a threat model. i dont have time to read the whole thing, but my skimming seems to be that the list length of actually used 4 digit pins is of comparable size to 6 digit pins, which is surprising but the paper still feels a little bit published-for-the-sake-of-publishing
The site, not the paper, got posted. If the site shouldn't count, maybe we shouldn't post paper summary sites?
Even though lay-person/marketing summaries of papers, and popular reporting summaries very often mess up academic results, or even just leave out details, personally I feel like having some hidden requirement to read through and understand the complete academic sources behind any article is onerous and might be unreasonable, especially if the paper is technical and inaccessible to a lay audience.
I appreciate it when someone like @kryogen1c recognizes and admits their gut reaction was based on incomplete information, that's as valuable to me as hearing comments that research and understand the sources.
> as a basic rule of thumb, any paper on cybersecurity that does not start the discussion with a reference attack vector and listed assumptions is probably garbage.
Actionable guidance for real world decisions is not the objective of academic research. The objective is to expand the human knowledge base (which hopefully translates to something practical at some point).
If the authors have the domain expertise to weigh in on PINs, but not on attack vectors, then that is what they should do. Let someone else draw the conclusions for IT managers.
Theory: as you ban a set of pins, for each pin the user wanted to enter, they will enter some similar pin that is not blocked, so the set of easy to guess pins is just a transposition once you know the banned pins and after some study understand what are the most obvious variations users will pick.
Ah yes, recall the era of 'Your password must contain at least 8 characters and one numeric character'. So you can get rid of all the passwords under 8 characters when you run your dictionary attack, and put a 1 on the end of every password that doesn't already contain any (since everyone just adds the digit 1 to their normal password when that happens). Want your users to use a symbol? They will put a dot.
Sigh. Shoutout to all of the people who's passwords end with 1. or .1
Time makes it worse - since all of the sites in that era had roughly the same rules about passwords, people adapted their passwords and just always used a password with dot one on every site. So the goal of protecting passwords from dictionary attacks became completely moot.
I mean, it's not as bad as I make it sounds but still. And as always, relevant XKCD: https://xkcd.com/936/
As far as the XKCD comic is concerned, if a brute force hacker knows this strategy for password generation, they'd only need to brute-force four "bits" (common words) of information. Of course, "knowing that strategy" is a monumental assumption, but password managers trump both those options any day.
I was reading through their slides wondering when they’d realize that the blacklist was stored in the IPSW…I guess it took them two dead phones to realize ;)
As an aside, Apple’s related MDM password policy is utterly bonkers, as it prevents passcodes with ascending or descending numbers adjacent to each other if you disable “simple” passwords. This was frustratingly humorous when I tried to use a long numeric code and it would constantly run afoul of that check due to statistics while a 6-digit “pattern” passcode would be accepted just fine.
> prevents passcodes with ascending or descending numbers adjacent to each other
That's just silly. Assuming it also disallows duplicates next to one another, that means that there is only 7 valid digits for position 2 through 4, aka 10 * 7 * 7 * 7 = 3730 possible combinations, less than half the search space.
Yeah, I pointed out in my bug report for this that the policy progressively penalizes longer passcodes because it gets harder and harder for a randomly selected one to be valid as passcode length increases. I doubt it got much attention paid to it, though, so out of spite I carried around the pattern code until I left.
Honestly, I didn't do a pin on my phone for years. I'm just not that worried about these kinds of things, because anything important has another password in the app.
At this point, the only reason I use a pin is to I can use the touch sensor to open my phone, and to "keep the honest people honest." I really only care about keeping my kids out of my phone.
IMO, what's more important than a secure PIN? I'd like to be able to lock down applications within Android / iOS instead of relying on the application to implement its own password.
> IMO, what's more important than a secure PIN? I'd like to be able to lock down applications within Android / iOS instead of relying on the application to implement its own password.
Oneplus has this on Android (called "App Locker"). It let's you choose a number of apps where you need to enter the system-level password/fingerprint/pattern/pin.
However, this is not separate from you login credentials, so it is not perfect IMHO. I would prefer to disable biometrics for the apps, but have it enabled for unlocking the phone.
I don't live with anyone, and there's nothing particularly sensitive on my phone except for BitWarden, which has its own master password. The only reason I use a pin to unlock my phone is so that I'm allowed to use Apple Pay.
Why on earth are the two related? You can't actually use Apple Pay without Touch ID or a pin.
Apple aspires to a future where there's no point stealing an unattended iPhone, because it'll have an unbypassable lock for sure, and hence zero stolen goods value.
True enough. Although there's some custom pieces that could be useful, like the big flat pieces used in the SHIELD Helicarrier for the runways: https://imgur.com/gallery/n5TEAhH
And Lego's designers could lend their expertise to creating some wiring routing and harnesses, or design some mounts/surrounds for breadboards. Or mounts for standard SoC boards like the ESP32 or Mega2560.
I think Apple should release a phone that you can hack yourself if you want to, so you could just write a program that grabs the screen instead of building a LEGO camera rig.
I think I'd be cool with it if they gave a good explanation that I could reason about, e.g. "your pin contains a 3 digit increasing sequence" or"your pin is the name of a popular book". I'd be even happier if it could give me a list of "here are some more secure pins similar to the one you chose"
Argh... wouldn't that make it brute force attacks more efficient? E.g. the suspect/victim is born on May 31st, his iPhone allows 10 PIN attempts. Your attack algorithm becomes:
1. Input "0531" on another iPhone's setup screen.
2. Try "0531" and the other suggested PINs, based on distance from thumb to the option.
Hehe that feels like itd be a good xkcd comic - “sorry your pin can’t be used because it’s a mersenne prime”, "sorry this is the first 4 digits of Tau", etc.
Your PIN can't be used because it is the smallest number not on our list of PINs that are too easy to guess for other reasons + the smallest previous number.
That reminds me of the story of the man who was ordered to be executed next week, but he is not allowed to know the day of his execution until the morning of.
He figures if by Friday morning he has not been told, then he will immediately know his execution is on Saturday, thus violating the Judge's order; therefore he cannot be executed on Saturday.
Knowing he can't be executed on Saturday, if on Thursday morning he has not been told, he knows he must be executed on Friday, thus violating the Judge's order. By induction it would violate the Judge's order to execute him on any day of the next week.
The following Tuesday he was thus completely surprised to be taken out to be executed.
I hypothesize without proof that if you enter "A, B, C, D" for any single-digit A, B, C, and D into http://oeis.org/ that you will find some reason why that is not a valid PIN.
7397: Digits 4-8 of the sequence "sum of iterated phi(n)".
1074: Sorry, that's digits 4-8 of log_21(8). Please try again.
6235: Sorry, that's digits 10-14 of an irregular triangle read by row's squarefree quadratic non-residues. Please try again.
2099: Sorry, that's digits 4-8 of the decimal expansion of the x-intercept of the shortest segment from the positive x axis through (2,1) to the line y=x.
Clearly, these are all way too easy to guess for an attacker for you to use them as a PIN number.
Maybe the simplest conclusion is that PIN isn't really any secure method. It's somewhat good for keeping most normal people away under normal circumstances. But if you really need to keep things secure than I have a hard time seeing that PIN is o way to go? I mean, passwords are not super good, and PINs (short anyway) are easy worse. There's a reason 2-factor auth exists after all...
"Really keeping things secure" has a lot of definitions. If your threat model is some guy on the other half of the planet half-heartedly trying out leaked passwords, 2FA is great. If your threat model is someone local specifically targeting you, 2FA kinda sucks, while a good password might do the trick. If your threat model is you getting abducted and hit with a wrench, then you should probably make some sort of shared key with multiple people where you need x% of all parts + invest if physical security.
We built an open source platform (qbix.com/platform) to power social apps and security was a major consideration. By default we encourage a user to type a pass phrase and give them suggestions based on {{possessivePronoun}} {{noun}} {{very}} {{possessivePronoun}} {{noun}}
But they can also attach another source, such as inputting an api key to NewsAPI and then to generate each suggestion we take a random news article and take three consecutive words from that article.
Actually, given there's usually quite limited amount of attempts to guess a pin, I don't really worry too much about somebody just guessing a 4-digit pin. So what if there's "only a 100/500/800" of combinations to try, if you have only 3/5 attempts and only 1 phone you care to break into?
What I do worry about, though, is somebody watching me enter the code. And I don't have any paper and a promotion-site with a catchy name to provide, but it feels like catching somebody rapidly entering 4 pseudo-random digits is quite a bit easier than catching them rapidly entering 6 or 8 pseudo-random digits.
I use 6 digit pins consisting ofthe same digit repeated 6 times. If I even have to switch it I'll forget it. Not sure why they have the requirement of a 6 digit pin and expect it to be better than a 4 digit one.
When I could use a 4 digit pin because then I could at least use one I have had for 20 years.
Why not use the 4 digit pin and then loop, appending the first two digits to the end to get a 6 digit pin? It’s somewhat easily guessed, but is a hell of a lot better than 333333...
Mine is a friend's birthday. Not a lover/ex, not even that close of a friend. So people that know me would never guess it, and for a stranger, it is just random number.
It also have the advantage of not having to save it in a password manager, since I have it on my calender (with a lot of other birthdays saved).
Exactly. If you're going to do a birthday-based PIN, it's important to consider that the 10s digit of month and year have heavily reduced search-space.
4-digit Birthday-pins are probably good as long as they're not your birthday or that of your kids, and you do the last 2 digits of year, last digit of month, last digit of day, go capture as much of the entropy from the date as possible.
On a side note, I remember back in 2004, a colleague born on Feb 29th, 1984 was unable to enter the U.S. H1B renewal website because someone forgot about leap years in their date validation logic.
> Not sure why they have the requirement of a 6 digit pin and expect it to be better than a 4 digit one.
Are you saying you can’t have a 4 digit pin? Because if you are then I just want to say that you can have 4 digits if you really want, it just defaults to a 6 digit during setup and there is an option to change to a 4 digit if you want.
Also. Password reuse if a bad thing. If you are really going to reuse a 20 year old pin, you might as well disable pin security completely.
> If you are really going to reuse a 20 year old pin, you might as well disable pin security completely.
What a foolish statement. Having a pin at all prevents a whole lot of attack vectors, even if weak. Like someone at random picking up the phone and getting personal information off it from any app lacking secondary authentication.
Having a weak pin won’t protect you from someone actively seeking to attack you specifically (a targeted attack). But most crimes are crimes of opportunity, not targeted, and any pin at all reduces the opportunity.
I recommend reading the paper, it goes in to how they address that. In short, they require the participant to at least remember the PIN for the duration of the task.
It is, however, only a five-minute task, so people may not select a super memorable PIN, just one they can remember for the duration of the task.
I think given the design of the task, people may be likely to use their actual device PIN for the task, because although nothing in the task suggests that you should do this, nothing suggests that you should not.
> Study of user-chosen 4- and 6-digit PINs collected on smartphones for device unlocking [...] a set of "easy to guess" PINs is disallowed during selection
So we are trying to avoid the now-common ones, which (aside from the obvious 4x one digit or 1234, etc.) will result in those becoming less common, and then to re-evaluate we have to submit one in a hundred PINs from all app users and sort of load balance who can use which PIN?
Or we just generate random ones and memorize them. If you care enough to install an app like this, this seems like the easiest solution such an app could offer: read a few bytes from /dev/urandom until there are 4 digits and display them on the screen.
what's the point of this effort? if their criteria is 40 guesses or less, when it's an automated attack does it matter whether it's 40 guesses or 9999? if you have access to repeatedly guess for up to 40 times without locking out the device you could keep it going on a loop to any other number.
either 4 digit pins are all bad, or they're not. do not pre-define some subset. all this is going to do, if someone was to take this seriously, is make it an extremely user hostile experience by some app. i already hate how some bank apps instead of morphing over to face ID or other secure methods of verification, or even Authy, will harass me to no end to modify the password to some gibberish that they've pre-determined to be 'safe'.
also, if you're building a brute force code breaker are you really going to program the 40 most probable pins upfront and then have a loop? i'd think that you just create n+1 loop starting at 0000 and that's it.
Recently I wanted to get on the roof of our building, but the new mgmt co had put a four digit combo lock on it. I eventually decided to brute force it and resigned myself to about a half hour of drudgery. Wanna guess what the combo was? My lucky day: 0000! Got it on the first try. (tears of joy emoji)^3
I mean mathematically of course the 6 digit is better than the 4. But they bring up some good points about how humans artificially shrink the search space.
But what is vastly superior is going into the settings and enabling the alphanumeric longer pins (aka passphrase).
It's variable length and does not give any clues as to the length, and it allows for a much larger character set.
This vastly increases the search space. I don't even know how long my passphrase is (never counted), but it is long enough that my wife still can't remember it despite repeatedly telling her what it is.
Before the biometric unlocks I never used a pin because it was a pain, but now with the biometrics I so rarely need it that I think it's a great compromise.
But you can guess any whole number if you have an unlimited amount of tries. if you are interacting programmatically with a live system there is always a limit to the number of tries that you can do.
iPhones and most other devices are limited. After a few tries, you will start down an increasing lock-out time for the next guesses. The back out does not apply to changing the PIN of an unlocked phone to see if that PIN gives a warning.
TL;DR: You can find the blacklist this way but not unlock a phone.
Obviously a lot of the banned PINs are years... interestingly they start at 1956 (and end at 2015). I guess 65+ year olds are in their target demographic.
I don't have to wonder, my PIN is 6 random digits that I memorized by using it a few times per day the first few days. It really isn't that hard with spaced repetition.
The Secret Lives of Numbers (2002: Golan Levin, Jonathan Feinberg, Shelly Wynecoop and Martin Wattenberg) is an interactive data visualization and online artwork, commissioned by Turbulence.org. An exhaustive empirical study was conducted to determine the relative popularity of every integer between zero and one million. The resulting information exhibits an extraordinary variety of patterns which reflect our culture, our minds, and our bodies -- forming a numeric snapshot of the collective consciousness. In The Secret Lives of Numbers, these analyses are returned to the public in the form of an interactive visualization, whose aim is to provoke awareness of one's own numeric manifestations.
The authors conducted an exhaustive empirical study, with the aid of custom software, public search engines and powerful statistical techniques, in order to determine the relative popularity of every integer between 0 and one million. The resulting information, presented in an interactive online information visualization, exhibits an extraordinary variety of patterns which reflect our culture, our minds, and our bodies.
For example, certain numbers, such as 212, 486, 911, 1040, 1492, 1776, 68040, or 90210, occur more frequently than their neighbors because they are used to denominate the phone numbers, tax forms, computer chips, famous dates, or television programs that figure prominently in our culture. Regular periodicities in the data, located at multiples and powers of ten, mirror our cognitive preference for round numbers in our biologically-driven base-10 numbering system. Certain numbers, such as 12345 or 8888, appear to be more popular simply because they are easier to remember.
The Secret Lives of Numbers (2002; Taiwanese documentation 2004)
The Secret Lives of Numbers was implemented in 2002 as a Java applet. Appropriately-configured browsers can present the online work here at Turbulence.org.
i was so disappointed when I realised they were emulating a USB keyboard to enter the PINs. That first picture made me think they had a actual robot finger for a moment ...
Just a heads up, since you seem to care about security: the strength is not in the properties (length, digits vs alphanumeric, that sort of thing) but in how you generated it. Use a secure random generator (e.g. `tr -dc 0-9 </dev/urandom | head -c 10`) and you can calculate exactly how strong it is. Think of something yourself or bash on the keyboard and all bets are off.
Also consider the attack vector: can an attacker just boot another OS and bypass the lock that way (so a super secure password won't fend off determined attackers anyway), or is it your disk encryption password? Is there a HSM that enforces a limited number of attempts (e.g. bank card)? Etc.
I find the pin thing after restart absolutely ridiculous. First, it's annoying. Not all of us face the same security threats, so a casual unlock is all that is needed for the vast majority of people in the world. Second, it defeats the "something you have and something you know" premise. It'd be best to just give users a choice.
Isn't it optional? I guess it can be turned off in Android settings, but I don't know, because I actually want it.
What infuriates me, on the other hand, is that since some Android version the fucking thing demands me to enter the PIN after some time (72 hours, I guess) of successfully using fingerprint-lock only. And I don't think you can turn it off in the settings, I tried, I didn't find a way. And this is really stupid, both because it's not their fucking business if I don't worry about my device security so much, and because the attack vector it protects from is exotic to say the least: so the attacker already has my fingerprints, is successfully using them for the last 3 days to unlock the phone, didn't let the phone to be turned off during that time, but somehow still didn't steal all my data and can only do that after 72 hours after last I unlocked my phone with a PIN? Fuck you, Google, or whoever thought this is a good idea.
as a basic rule of thumb, any paper on cybersecurity that does not start the discussion with a reference attack vector and listed assumptions is probably garbage.
a charitable interpretation would be that they left out such details in the leading summary, but those details matter more than the actual findings. if im an IT manager and trying to decide how to lock phones, an accurate threat model is more important than the mitigations. good mitigations against the wrong threat is much, much worse than bad mitigations against the correct threat
EDIT: woops! i did the bad thing thats ruining society and read the web article instead of the paper. the paper has a whole section on picking a threat model. i dont have time to read the whole thing, but my skimming seems to be that the list length of actually used 4 digit pins is of comparable size to 6 digit pins, which is surprising but the paper still feels a little bit published-for-the-sake-of-publishing