How to Create a More Secure Passcode on Your iPhone or iPad

[MacRumors]

Apple's iPhones have long been protected by numeric passcodes, giving iOS users a way to protect keep their devices safe from hackers and prying eyes. Over the years, passcodes have been supplemented by Touch ID, Apple's fingerprint recognition system, but the passcode is still the iPhone's main line of defense.

A passcode is required to set up Touch ID, and Touch ID is automatically disabled after 48-hours until a passcode is input by an iPhone or iPad's owner. In the United States, passcodes are especially important because the law suggests that while law enforcement officers can require you to provide a fingerprint to unlock a device, the same is not true of a passcode.

For a long time, passcodes were four-digit numeric codes by default, but with iOS 9, Apple began using a six-digit passcode as the default option. Six-digit passcodes offer 1 million possible combinations instead of 10,000, making a passcode harder to crack.

Apple doesn't advertise it, but the iOS operating system offers an option to make your passcode even more secure through the use of an alphanumeric passcodes or custom length numeric passcodes. Alphanumeric passcodes contain letters and numbers. Both alphanumeric and custom numeric passcodes can be much longer than four or six digits.


Click here to read more...

Article Link: How to Create a More Secure Passcode on Your iPhone or iPad

 

[dwaltwhit]

I was not aware that I could be compelled to unlock my phone via fingerprint but not passcode.

 

[thasan]

I was not aware that I could be compelled to unlock my phone via fingerprint but not passcode.

Yes. So the best way is to switch off your phone if you don't want others to see (hopefully nothing illegal in your phone).

 

[DCYorke]

I would recommend using spaces instead of hyphens in the password, that way you don't have to switch keyboards while typing it in.

 

[jclo]

I would recommend using spaces instead of hyphens in the password, that way you don't have to switch keyboards while typing it in.

Yep, good tip. No need to use hyphens. That's just now 1Password generates word-based password strings as a default.

 

[Trik]

I'd love an app that when I removed my Apple Watch, it turned off thumbprint on all my devices and required the passcode.

 

[ArtOfWarfare]

Battery Staple Horse Correct

Also, I feel like 1234567 would be a better password on an iPhone than on a computer. Like, on a computer that's one of the first thing you guess. But on an iPhone, that would mean you went through the effort of setting up an alphanumeric password of custom length. And you chose what is generally regarded as one of the worst passwords possible.

 

[Black107]

Yes. So the best way is to switch off your phone if you don't want others to see (hopefully nothing illegal in your phone).

If you spam the sensor with unregistered fingers 5 times, it will ask for your password regardless if you put the correct finger on it after the unregistered fingers. This would be less conspicuous than shutting your phone down. In a pinch you could also restart.

 

[obafgkm]

It is too bad that this isn't specified for the iPod Touch in the title. Nothing in the description excludes the iPod Touch (I know that the iPod Touch doesn't have TouchID, but this is about the passcode).

The iPod Touch, the forgotten stepchild of iOS.

 

[Major Tom 74]

Doing this since my ip5s , would like to see some stats on 80ms delay, number of digits and the time it takes to brute force it , also , can the 80 ms be ****ed with?

 

[Jeremy1026]

Doesn't matter when the FBI gets their way and gets the backdoor they have been itching for.

 

[KALLT]

Also, I feel like 1234567 would be a better password on an iPhone than on a computer.

But as we've seen now, Apple might be able to override the brute-force prevention and a trivial password like 1234567 is one of the first things that a reasonable ‘brute-forcer’ will attempt. Computers are vulnerable to this already, because the hard drive is accessible and the encryption key is often derived from a password (at least that is the case with FileVault; you can just reboot into Recovery and try as often as you like).

 

[nt5672]

Doesn't matter when the FBI gets their way and gets the backdoor they have been itching for.

That is up to you and I. Apple has stuck their neck out. Now the government is quietly trying to cut their head off. They only way they, the government win, is if you an I are silent and don't say anything. Now is the time to call and write and tweet, and make whatever noise can be made because next month will too late.

 

[iOSFangirl6001]

An alternate title to this article could also be "EZ Ways to **** off the Feds" lol

 

[PalindromeB0B]

 

[boccabella]

In order for this to be effective wouldn't you also need to secure your iCloud account in the same manner?

 

[tedson]

One other trick to make kracking tougher is to put a number or symbol between the 2nd and 3rd or the 3rd and 4th letter or the last and 2nd to last letter in each word. That makes using combinations of dictionary words much stronger.

 

[Porco]

Even simply switching from a digit-entry screen to the alphanumeric keyboard is better as gives less information away to anyone trying to gain entry, even if you left it with 4 digits as a passcode, because there are so many more possibilities on top of those constructed with some of the 10 possible digits, as well as the unknown length of the passcode (which is telegraphed immediately when you see 4 or 6 dashes on the screen).

Obviously it's almost kind of academic, because if you bother to switch to alphanumeric you might as well use a better passcode than just 4 digits.

 

[ptb42]

Doing this since my ip5s , would like to see some stats on 80ms delay, number of digits and the time it takes to brute force it , also , can the 80 ms be ****ed with?

You can do the math: 80ms * 10,000 attempts is 800 seconds, or 13.33 minutes. If you increase it to 6 digits, that's 80,000 seconds or 22.22 hours.

However, the significance of 80ms depends on the iPhone model, or more specifically -- the processor. iPhone 5c or earlier used an A6 processor or earlier. iPhone 5s or later uses an A7 or later processor.

The earlier iPhones (since the 3G, I think) with A6 and earlier enforce the 80ms per attempt by requiring the password to be run through PBKDF2 with enough iterations that it requires 80ms on the encrypted device. Each iteration, it does an operation that uses the device UID burned into the processor at manufacturer.

The device UID can't be read directly. So, a brute-force attack on any other device but the specific encrypted iPhone would require brute force search of the device UID keyspace as well. The device UID is a 256-bit AES key, making this difficult in a reasonable amount of time, or at a reasonable cost.

The later iPhones with the A7 and later added a Secure Enclave. This enforces a limit that changes with the number of consecutive failed attempts. The first 4 attempts, there is no delay. After that, it increases rapidly to as much as 1 hour after 9 attempts. The Secure Enclave even enforces this limit if the device is restarted (and presumably includes a power-cycle).

Unless you choose an easily-guessed 4-digit passcode, it would take over a year to search the entire 10,000 key space, at 1 hour per attempt.

You can find this in https://www.apple.com/business/docs/iOS_Security_Guide.pdf, on page 12.

There have been unconfirmed claims that Apple says they could still compromise the Secure Enclave with a backdoor'ed iOS. But, that seems to contradict their security guide, and I can't imagine why they would go through all the effort to implement a vulnerable Secure Enclave. So, I'm waiting to see an authoritative citation.

 

[arn]

You can do the math: 80ms * 10,000 attempts is 800 seconds, or 13.33 minutes. If you increase it to 6 digits, that's 80,000 seconds or 22.22 hours.

However, the significance of 80ms depends on the iPhone model, or more specifically -- the processor. iPhone 5c or earlier used an A6 processor or earlier. iPhone 5s or later uses an A7 or later processor.

The earlier iPhones (since the 3G, I think) with A6 and earlier enforce the 80ms per attempt by requiring the password to be run through PBKDF2 with enough iterations that it requires 80ms on the encrypted device. Each iteration, it does an operation that uses the device UID burned into the processor at manufacturer.

The device UID can't be read directly. So, a brute-force attack on any other device but the specific encrypted iPhone would require brute force search of the device UID keyspace as well. The device UID is a 256-bit AES key, making this difficult in a reasonable amount of time, or at a reasonable cost.

The later iPhones with the A7 and later added a Secure Enclave. This enforces a limit that changes with the number of consecutive failed attempts. The first 4 attempts, there is no delay. After that, it increases rapidly to as much as 1 hour after 9 attempts. The Secure Enclave even enforces this limit if the device is restarted (and presumably includes a power-cycle).

Unless you choose an easily-guessed 4-digit passcode, it would take over a year to search the entire 10,000 key space, at 1 hour per attempt.

You can find this in https://www.apple.com/business/docs/iOS_Security_Guide.pdf, on page 12.

There have been unconfirmed claims that Apple says they could still compromise the Secure Enclave with a backdoor'ed iOS. But, that seems to contradict their security guide, and I can't imagine why they would go through all the effort to implement a vulnerable Secure Enclave. So, I'm waiting to see an authoritative citation.

Apparently it's possible even with secure enclave

http://techcrunch.com/2016/02/17/why-apple-is-fighting-not-to-unlock-iphones-for-the-government/

Apple says that the things that the FBI is asking for are also possible on newer devices with the Secure Enclave. The technical solutions to the asks would be different (no specifics were provided) than they are on the iPhone 5c (and other older iPhones), but not impossible.

 

[gnasher729]

Doesn't matter when the FBI gets their way and gets the backdoor they have been itching for.

Of course it matters. The FBI wants to install new software so that the phone doesn't wait longer and longer when you type in an incorrect passcode, and so that it doesn't erase the phone after 10 attempts. They still need to check 10,000 combinations with a 4 digit passcode (about 15-20 minutes), 1,000,000 combinations with a 6 digit passcode (a day), ... and 5 1/2 years for 8 digits + lowercase + uppercase letters.

 

[von franklin]

if you don't want stuff to be seen on your phone do stuff face to face.

 

[ptb42]

Apparently it's possible even with secure enclave

http://techcrunch.com/2016/02/17/why-apple-is-fighting-not-to-unlock-iphones-for-the-government/

Yes, this is the same trail of assertions I've seen earlier. It hinges on the contention that Apple can update the firmware for the Secure Enclave, and remove the enforced delay between attempts.

But, I'm skeptical because I find it hard to believe that Apple would leave that door open. That would mean the A6 processor (and earlier) is actually more resistant to brute-force attacks on the combined device UID and passcode, due to the required iterations that require 80 ms.

 

[arn]

Yes, this is the same trail of assertions I've seen earlier. It hinges on the contention that Apple can update the firmware for the Secure Enclave, and remove the enforced delay between attempts.

But, I'm skeptical because I find it hard to believe that Apple would leave that door open. That would mean the A6 processor (and earlier) is actually more resistant to brute-force attacks on the combined device UID and passcode, due to the required iterations that require 80 ms.

This isn't speculation. This is Apple telling Techcrunch "yes, it's possible".

arn

 

[ptb42]

This isn't speculation. This is Apple telling Techcrunch "yes, it's possible".

No, this was Techcrunch claiming that Apple told them that.

There was no attribution, and no source document.

As you may remember, the "error 53" was "intended behavior", until someone at Apple other than a corporate mouthpiece investigated.