Live data from Hacker News

Boffins reveal password-killer 0days for iOS and OS X

theregister.co.uk

71–80 of 144 posts

Re: Boffins reveal password-killer 0days for iOS and OS X

#71
post #59
post #47

Earlier quoted context omitted.

Where should the state be kept, on a server?

No where electronically. A simple word or phrase in the user's mind would do. Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.

The problem with this is that different passwords have different requirements, which must now be remembered and entered every time you need that particular password.

I suppose "immutable state" would be a nice compromise, but the method is fundamentally less flexible than something with state.

Re: Boffins reveal password-killer 0days for iOS and OS X

#72
post #59
post #47

Earlier quoted context omitted.

Where should the state be kept, on a server?

No where electronically. A simple word or phrase in the user's mind would do. Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.

That's hard to manage outside of a few specialized environments where you have total control of the user and applications. The problem which comes to mind is that there's no way to use that system when so many sites have incompatible restrictions on length and character set – i.e. I have accounts on systems where the minimum password length is longer than the maximum somewhere else – and I'd still need a manager to track my random answers to security questions.

Rather than trying to make small improvements in the inherently-limited password model we should be focusing on changing the model entirely to depend less on what a human can comfortably remember: that's things like SSO to avoid the need to manage hundreds of accounts and also things like U2F to use strong public-key encryption.

Re: Boffins reveal password-killer 0days for iOS and OS X

#73
post #22

From the paper: > Since the issues may not be easily fixed, we built a simple program that detects exploit attempts on OS~X, helping protect vulnerable apps before the problems can be fully addressed. I'm wondering if the tool is publicly accessible, couldn't find any reference to it.

was wondering the same thing... finding items with more than 1 application is the important part. so this is a start: security dump-keychain -a > keychain.txt && egrep -n "applications \(([2-9])\)" keychain.txt

Then just look at the item that contains those line numbers and see whats up. You will have some show up on an unaffected system. This is what my output looks like: http://puu.sh/ishaP/675695b11e.png

* disclaimer, that egrep regex is shit.

Re: Boffins reveal password-killer 0days for iOS and OS X

#74

Earlier quoted context omitted.

>Just like Windows. Strange thing eh? Not strange if you grasp the fact that malware is just a program that has elevated access. For me it was strange how can Apple market their system as virus-free. Now that's ridiculous.

Yes, to any techie the lie is obvious. I just wonder what the vast userbase of uneducated people (seniors, teen bloggers, ironically education institutions, etc) who moved over to macs because they bought the lie will feel when they too later discover that the promises were a lie. Because unlike Microsoft, Apple doesn't have a battle hardened OS where security has been worked on systematically, for over a decade. And…

> who moved over to macs because they bought the lie will feel when they too later discover that the promises were a lie.

what? I thought they bought macs so we wouldn't need to give free tech support ;)

Re: Boffins reveal password-killer 0days for iOS and OS X

#75
The first defense they can perform is to change the automatic checks in the App Store review process to identify the attack in a malicious app and stop it from being approved. This could be fairly easy, of course Apple doesn't tell anyone what they do in this process so we have no way to verify it. Still you have to identify how the process could be hidden but since it uses known API calls in an uncommon way, I think this is quite doable.

The second defense is more complex, changing the way Keychain API works without breaking every app out there is much more complex. Not knowing much about this is implemented it might take a lot of testing to verify a fix without breaking apps.

The last thing they can also do is to build a verified system tool that checks the existing keychain for incorrect ACL usage. You can't hide the hack from the system. This way Apple could fix the ACL to not allow incorrect usage and not give access where it doesn't belong. I think this is fairly easy to do since it will break very little.

This is why building security is hard no matter who you are and everyone gets it wrong sometimes. At least Apple has the ability to readily (except for point 2) repair the problem, unlike Samsung having to have 800 million phones somehow patched by third parties to fix the keyboard hack.

Re: Boffins reveal password-killer 0days for iOS and OS X

#76

Earlier quoted context omitted.

>This would only show if you've been exploited already What would indicate a compromise?

If the ACL of a keychain item contains an app that isn't supposed to have access to that keychain item then that would indicate a compromise.

Ah ok that makes sense. Thanks very much.

Re: Boffins reveal password-killer 0days for iOS and OS X

#77

That paper is rife with confusing or just plain wrong terminology, and the discussion jumps between Android, iOS, and OS X, making it really hard to digest. I think these are the bugs they have discovered, but if anyone could clarify that would be great: • The keychain can be compromised by a malicious app that plants poisoned entires for other apps, which when they store entries that should be private end up readabl…

The URL Schemes are unauthenticated, but the main problem is that duplicates are resolved by the host OS at install time, either as first-installed app wins (OSX) or last installed app wins (iOS).

Re: Boffins reveal password-killer 0days for iOS and OS X

#78
post #36
post #34

Earlier quoted context omitted.

Rootless is more about securing the OS files and processes from malware.

Isn't this similar? Rootless is strengthening the sandbox against malware. Anyone on the new Mac version want to test this?

I don't think so, especially since the Keychain being affected by this is a user file. Rootless protects system files.

Re: Boffins reveal password-killer 0days for iOS and OS X

#79
post #59
post #47

Earlier quoted context omitted.

Where should the state be kept, on a server?

No where electronically. A simple word or phrase in the user's mind would do. Rather than being stored for later retrieval, complex passwords could be generated on-the-fly (when needed) using this word/phrase as input combined with other input such as URLs, hostnames, service names, etc.

IIUC, you're talking about using what amounts to a user-managed password-generation schema. This seems like a weak (re: entropy) and ultimately very user-hostile approach to password management. Having known people who use such approaches, they still have to remember at some potentially distant time just what cocktail of fields they used in their password formula for this site. That is, the burden of password memorization remains but they don't gain much for their trouble.

I hear of such schemes from time to time but I've never seen them subjected to real attack analysis. I strongly suspect that these mostly generate surprisingly weak passwords.

Re: Boffins reveal password-killer 0days for iOS and OS X

#80
post #8

"Boffins"? Isn't that rather dismissive, as in "oh, look at what those crazy boffins cooked up now!"?

It's the British IT Tabloid. Its style is not to be taken entirely seriously.

See their units convertor: http://www.theregister.co.uk/Design/page/reg-standards-conve...

A! Yahoo! Related! Story! Is! Probably! Headlined! With! Exclamation! Marks!

It uses terms like bonk-to-pay (contactless payment), mobes (mobile/cellular phones), Chocolate Factory (Google), Blighty (Britain) etc.

Post reply on HN