91–97 of 97 posts
Humans being abysmal PIN and password generators, a decent fraction of phones can probably be unlocked within 5 attempts by just trying 123456, 123123, 111111, 654321, 000000. Unless/until the phone forces the user to learn rather than select a PIN that's probably going to remain the biggest vuln.
Earlier quoted context omitted.
This is plainly brilliant. Just done that and the interface seems to not give any clue about the expected number of digits. Meaning that an attacker have no mean to even estimat the time needed to unlock. One could only figure out that complexity of password increased after failing all attempts with less digits (which will already take a lot of time). But of course alphanumerical would be even safer.
But why not take it a step further and present the standard KB? That would be a slight inconvenience, with a massive gain in confusion for anyone trying to guess their way in.
Thanks for the down votes.
Earlier quoted context omitted.
SEMs are not that expensive. The cheap ones on eBay are $12-14K. The more expensive Chinese ones are closer to $200K. A security company can easily afford either.
I don't think the acquisition of a SEM is the barrier to performing this kind of attack. It's still extremely hard
Earlier quoted context omitted.
You misunderstand the SEP. It contains an externally unreadable private key baked in at manufacturing time that encrypts protected data. Your "wires" would read garbage. The iOS security white paper is worth a read. Perhaps a nation-state actor could shave down the processor and read that key with a SEM or some crazy thing, but that's literally how far the design is supposed to have pushed iOS security. Which is what…
> Perhaps a nation-state actor could shave down the processor and read that key with a SEM or some crazy thing, but that's literally how far the design is supposed to have pushed iOS security. Which is what makes this hack so embarrassingly bad (if confirmed). Shaving down the processor is hard but still possible . A government with a billion-dollar budget can probably do it, if they want, including after practicing…
The only reason your Linux laptop would be more secure than an iPhone is if you were using a high-entropy key to unlock it every time you wanted to use it -- and the iPhone wasn't. That's it. But remembering high entropy keys without storing them in some less secure manner is so inconvenient and failure-prone for most people that it's actually a less secure design than Apple's SEP-assisted approach. And you could opt-in to a high entropy key on an iPhone if you wanted to, so even that is a false comparison.
[1] https://images.apple.com/business/docs/iOS_Security_Guide.pd...
If this gets stolen and put on the black market, that would be a good thing. Because then Apple can buy one, figure out what vulnerabilities it's using, and patch them.
Earlier quoted context omitted.
I love it, but the XKCD wrench comic is fresh in my mind. When I was mugged, they just made me unlock the phone right there on the street.
It would be nice to have a panic code that one could type in, making it look unlocked, hiding apps a user could mark as secret, and optionally sending a security/tracking alert. This could also thwart a cracking device by making it look cracked at a shorter code, but giving no actually useful info.
If this actually works there has to be some huge, embarrassing vuln in Apple's Secure Enclave Processor on par with the "CTS Labs" AMD secure coprocessor hoopla that hit the news just this week.[1][2] The SEP is supposed to enforce a time delay between passcode attempts to prevent this sort of brute forcing. The timer could be defeated in older models by cutting power at just the right time, but Apple's whitepaper sa…