> Not for the most part. In fact, we encourage using credential managers as opposed to trying to remember all of your passwords. In general, this is a better approach than reusing passwords or storing them insecurely. While iLeakage can recover credentials that are autofilled into a webpage, we note that many platforms require user interaction for autofill to occur.
Why would use of a credential manager change this? If its leaking something out of memory it should effect all memory within the Safari process space? I'm not familiar enough in this area to understand this caveat.
They're basically saying:
a) you are safer with a password manager than without, in general, despite it not providing any additional security for this particular attack; it is also not any more vulnerable. having a password manager doesn't make you more likely to be caught by this attack (because the last thing they want to do is accidentally convince people to stop using them, in favor of 'newpassword2')
b) you are safer yet if you turn off automatic autofill and instead use a hotkey or some other form of user interaction
One of their demos was showing how they could recover a username/password combination for a third-party site (Instagram), which was specifically possible because a password manager was in use that auto-filled those fields, putting them in memory. One possible reading of that is that you'd be immune if you didn't use a password manager, didn't let your browser remember the password, and just typed it in each time. There's a bunch of reasons that's a dumb objection:
- Having a password manager is good for lots of other reasons, and at least means that only one website is compromised if the password is stolen
- Their technique could probably also steal session tokens, which isn't quite as bad as stealing a password but is still bad.
- Password managers can be configured to require a click to fill in the password, which also defeats this attack.
I think they’re saying that you’re not more vulnerable with a password manager than you would be without one. I.e. they can recover passwords that have been autofilled into a page, just as if you entered the password manually, but they can’t read all your stored passwords directly out of your password manager.
My understanding is that this the vulnerability only allows memory access to related Safari/Webkit processes (specifically those sites that were opened with a window.open call). So passwords stored in a separate password manager app are inaccessible unless that app autofills the password into the compromised Safari window/process.
>Why would use of a credential manager change this?
Change what?
>If its leaking something out of memory it should effect all memory within the Safari process space?
AFAIU, Safari generally puts different origins and extensions in different address spaces, so it's not vulnerable to speculative execution attacks. This attack found a way to make 2 different origins share the same address space. I'm assuming the attack doesn't apply to extensions. From the paper:
>We begin by abusing Safari’s site isolation policy, demonstrating a new technique that allows the attacker page to share the address space with arbitrary victim pages, simply by opening them using the JavaScript window.open API.
> Not for the most part. In fact, we encourage using credential managers as opposed to trying to remember all of your passwords. In general, this is a better approach than reusing passwords or storing them insecurely. While iLeakage can recover credentials that are autofilled into a webpage, we note that many platforms require user interaction for autofill to occur.
Why would use of a credential manager change this? If its leaking something out of memory it should effect all memory within the Safari process space? I'm not familiar enough in this area to understand this caveat.