I didn't see that in the article. Can you point it out? (Seriously if this is true, I really want to know.)
Do you have any evidence this was introduced in 7.0.6?
"Mandt said he did not disclose the issue to Apple"
We really need to stop paying people — directly or indirectly — for irresponsible disclosure.
I was a Palm programmer at the time. I have to call "bullshit."
First, you can set the password to much longer than 4 characters.
Secondly, any parent can tell you that even without "wipe after 10 failed attempts" turned on, the iPhone will not allow you to enter PINs continuously. You'll start getting increasing delays fairly quickly, including delays that are quite long.
It would if full disk encryption was on and the user didn't leave their encryption key/password.
No, CVE-2014-1266 is 10.9 and 10.9.1 only. You're right about it also applying to iOS 6, but that's what the person you're replying to already said.
There's no contradiction there. You are running a seed of 10.9.2, not 10.9.2.
I'm more curious if Apple will put out a fix BEFORE 10.9.2 ships; rumours still peg 10.9.2. a few weeks away.
The source is available; how does "security through obscurity" apply at all?
Um, sure there is. Search for SSLHashSHA1.update; it's in the second group of them.
10.7 probably isn't vulnerable, as it predates iOS 5 (which doesn't have this flaw).
If 10.8 is vulnerable, the suggested upgrade would be 10.9.3 anyway. (10.9 has the same requirements as 10.8, and is a free upgrade.)
I would like to see an article that explains which versions are vulnerable, however.
This is a fascinating problem. I can see the feature being incredibly valuable, yet awful as it's currently implemented. Is there an approach to doing this safely?
Yes. Won't someone think of the small developers?
-- A small developer.
And a bad month for Samsung.
Perhaps they are. It is remarkably difficult to secure a large code base.
Though I would hope that NFC is new enough that it would be coded securely right from the start.