A very interesting article, and it highlights an attack vector that I wasn't aware of. So, thanks for publishing!
One thing the article lacks - it talks about (and even recommends) being able to pick a different passphrase, but offers no guidance for how someone might go about doing that.
I looked, but couldn't see anything. Not in Chrome, not in passwords.google.com, not in Android.
Yeah setting a passphrase kills the online password manager.
I have long since switched to using 1Password for everything, but it was seeing passwords.google.com for the first time that freaked me out enough to switch to a passphrase.
Interesting find. This should apply to any online password manager, though. Shouldn't this apply even to sites like LastPass? Or anything where your master password is entered via a "3rd party" software (browser in this case). I am excluding 1password or anything with a standalone desktop software. But the browser-plugin for your password manager could be just as bad attack vector.
Storing your master password anywhere is an obvious fuckup. The story here is that just by having a valid session you can export all passwords from google password manager without it ever asking for authentication.
Small correction - it asks for your device password (try it yourself if you use the chrome password manager).
In this case something with NoMachine exposed/disabled the device password as well.
Essentially the OP's configuration allowed an attacker unfettered access to the machine while a "blessed" chrome session was still active and had their master password stored in Safari.
If you view passwords in Google Chrome, it asks for the device password. If you view them from the online Google Passwords Manager website, it doesn't ask for the device password (how would it?).
Don't you also have to have the 'Don't ask again on this computer' option selected the first time you login to Google with 2FA?
It looks like that's the default, but that's another good way you can avoid this issue - if you do have to log in to Google on a machine with lower security, be sure to uncheck that box.
It’s difficult because if you lose access to your 2FA before you remember to remove it from accounts, which would be the typical scenario, you’re in a bad spot. It happened to me once with PayPal after being forced to quickly change my phone number.
The lesson here is to not leave your password manager logged into any machine other than the ones you know are secure themselves. I only do for my phone and personal machine.
That makes sense and is a valid reason to allow removing 2FA without having your (lost) 2FA. However there's still the fact that there was no notification that it was removed.
Agreed. I've probably never used Google Password Manager, but made the mistake of saving passwords once or twice on throwaway machines. And I was easily able to figure out how to delete them. Also I don't know which part of the security model was unclear. There's still a master password, like 1Password does. If anything, it has another layer of protection that comes from Google account and its 2FA.
If I had logged into my actual password manager (1Password, the one I chose), and saved the master password that that somewhere that could be autofilled, then I'd be right there with you.
That's not what happened at all though. Chrome collected passwords over the years, Safari saved the wrong one, and it leaked all my old passwords - and a few ones I hadn't changed yet.
I spend a large amount of time admitting my mistakes in the article, Google's approach to 2FA is still really surprising to me and a lot of others are hearing about it for the first time.
I think he’s saying that your Google account password is your master password in this case, and was leaked.
I get what you’re saying though, no one expects Google’s password management to be so riddled with holes. Encrypting the view or usage of the rest of your passwords with a master password needs to be mandatory, not optional.
I’ve always used Keepass stored on Dropbox and enter my master password everyday, multiple times as it logs out after 3 minutes.
I do save some passwords in Firefox but don’t sync those, and 2FA through Microsoft Authenticator (SMS only when it’s the only option).
That’s still not perfect but your attack surface doesn’t exist.
This is all really complex for the average person and it took me years as a relatively astute developer to handling properly. A device (something you have) biometric (something you are) authentication should resolve all of these issues in an easy way that you don’t have to think about, and I’m looking forward to ‘sign in with Apple’ to become a universal login for this reason. They nailed this problem, now we need Microsoft and Google to do the same.
The author seems to have missed the true root cause here here. Which was exposing VNC and NoMachine to the internet in the first place. These services should have been accessed through ssh port forwarding (or using a VPN). Password auth should always be disabled on ssh and keys should be used.
Very few daemons are secure enough to expose to the open internet. OpenSSH is one of the few.
(And, if possible, even network access to ssh should be blocked by the cloud provider's firewall. Access should only be permitted from the user's public IP)
LOL, I was wondering how long it would be before someone commented, ignoring the entire first part of his post and blames the victim. Not that long it turns out!
As I was wading through paragraph after paragraph where the author acknowledged fault and berated himself for it, I was thinking, "This is annoying, but I know if he doesn't write all this crap, someone out there will just ignore everything else he writes. They probably will anyways..."
And sure enough, here you are!
Moral of this story for people who write things online: Don't worry about the critics. You can't please them no matter what you write, or how much you bow and scrape and beg forgiveness for your human frailty up front, there will always be someone who will be a jerk.
Yes, the author pointed out their other mistakes. But the author seemed to have missed this important mistake completely. I "ignored" nothing. I explained the mistake for their benefit and for others. Not out of any maliciousness or to shame them.
The appropriate response would be gratitude for the feedback. The author and yourself are being needlessly defensiveness.
If you use the Chrome sync phrase, Google cannot access your passwords and thus they are not visible in the online password manager. Furthermore, if you delete passwords client side, i.e. from the password manager in Chrome, you are also deleting the passwords server side. This allows you to delete all passwords at the same time using the classic Ctrl-Shift-Canc.
This https://www.dropbox.com/s/s3tzbree2ddjnar/Screenshot%202020-... is the password manager I see in chrome, and I see no way to delete more than one at a time, or to select more than one at a time.
I assume by "Canc" you mean the DEL key? Regardless, there's no way to multiple-select items.
Hi! The server in question can definitely handle HN and a half, but, there's 9 different places to set the "max number of open file descriptors" on Linux nowadays, and I missed one of them.
> The first factor is the password, but the second factor is the device's lock screen / password.
> I enquired how did they know a lock screen was actually set up, let alone solved recently, and the answer was: "on Android, we know - for Windows & macOS, we'd probably need browser extensions".
This blew my mind. How many Google security experts worked on their model and how did they all think "...and obviously we can assume every user has a secure login set up on every machine"?!
Interesting sequence of mishaps there. I think the key takeaway is more like being very aware of how secure you consider a machine to be and consider what to log in to accordingly. I.E. never ever log into a high-priority account on a low-security remote device.
I consider my Google account to be very high priority in terms of keeping the login secure. Accordingly, I would never log into it on a remote machine like that. I keep APP on, and I'm not sure if I even could, what with the security key requirements. But such a remote machine is IMO always just too vulnerable to various types of compromise. One of the reasons I still have a Google account, for all of their faults, is that I think they're the best in the industry for blocking account takeover attempts.
Article OP didn't say why he felt the need to log into his Google account on a remote server meant for CI builds and with relatively low security. I think that would be the first point to address. There's just too many ways to compromise things once you make that mistake, and I wouldn't want to count on all of the other security bits being just right for an attacker not to be able to escalate that kind of access somehow.
> And of course, Google Chrome synchronizes these passwords to their servers. So that if you log into Chrome from another device, you have access to all of these
Usually Chrome prompts me to enter my windows pin before showing me my password. The attacker also needs to know my Windows pin/pass to see those passwords.
36 comments
[ 3.2 ms ] story [ 88.0 ms ] threadOne thing the article lacks - it talks about (and even recommends) being able to pick a different passphrase, but offers no guidance for how someone might go about doing that.
I looked, but couldn't see anything. Not in Chrome, not in passwords.google.com, not in Android.
I have long since switched to using 1Password for everything, but it was seeing passwords.google.com for the first time that freaked me out enough to switch to a passphrase.
In this case something with NoMachine exposed/disabled the device password as well.
Essentially the OP's configuration allowed an attacker unfettered access to the machine while a "blessed" chrome session was still active and had their master password stored in Safari.
It looks like that's the default, but that's another good way you can avoid this issue - if you do have to log in to Google on a machine with lower security, be sure to uncheck that box.
A better title should be "How I leaked by master key"
It was surprising that you could disable 2FA without using your 2FA. That seems like a big flaw.
The lesson here is to not leave your password manager logged into any machine other than the ones you know are secure themselves. I only do for my phone and personal machine.
The author's domain seemed familiar, and I noticed a previously popular post which had sort of similar tone, so I think there might be a pattern of writing catchy posts like these. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
That's not what happened at all though. Chrome collected passwords over the years, Safari saved the wrong one, and it leaked all my old passwords - and a few ones I hadn't changed yet.
I spend a large amount of time admitting my mistakes in the article, Google's approach to 2FA is still really surprising to me and a lot of others are hearing about it for the first time.
I get what you’re saying though, no one expects Google’s password management to be so riddled with holes. Encrypting the view or usage of the rest of your passwords with a master password needs to be mandatory, not optional.
I’ve always used Keepass stored on Dropbox and enter my master password everyday, multiple times as it logs out after 3 minutes. I do save some passwords in Firefox but don’t sync those, and 2FA through Microsoft Authenticator (SMS only when it’s the only option). That’s still not perfect but your attack surface doesn’t exist.
This is all really complex for the average person and it took me years as a relatively astute developer to handling properly. A device (something you have) biometric (something you are) authentication should resolve all of these issues in an easy way that you don’t have to think about, and I’m looking forward to ‘sign in with Apple’ to become a universal login for this reason. They nailed this problem, now we need Microsoft and Google to do the same.
Very few daemons are secure enough to expose to the open internet. OpenSSH is one of the few.
(And, if possible, even network access to ssh should be blocked by the cloud provider's firewall. Access should only be permitted from the user's public IP)
As I was wading through paragraph after paragraph where the author acknowledged fault and berated himself for it, I was thinking, "This is annoying, but I know if he doesn't write all this crap, someone out there will just ignore everything else he writes. They probably will anyways..."
And sure enough, here you are!
Moral of this story for people who write things online: Don't worry about the critics. You can't please them no matter what you write, or how much you bow and scrape and beg forgiveness for your human frailty up front, there will always be someone who will be a jerk.
The appropriate response would be gratitude for the feedback. The author and yourself are being needlessly defensiveness.
Since the incident I've looked into changing the default bind address of the macOS VNC server, and... they definitely don't mean for users to do that.
This has nothing to do with Google Password Manager.
You leak your password storage master password, you're going to have a bad day..
There is no way to delete all of your passwords saved by Google other than one. at. a. time.
There are lots of instructions on how to do it ( https://support.google.com/accounts/thread/3509905?hl=en , https://support.google.com/chrome/answer/95606?hl=en , https://support.google.com/chrome/thread/5688847?hl=en , https://superuser.com/questions/1106689/how-do-i-delete-all-... )
None work (as of late 2019, the last time I tried).
Everything's back to normal, thanks for caring.
> I enquired how did they know a lock screen was actually set up, let alone solved recently, and the answer was: "on Android, we know - for Windows & macOS, we'd probably need browser extensions".
This blew my mind. How many Google security experts worked on their model and how did they all think "...and obviously we can assume every user has a secure login set up on every machine"?!
(It's already bad enough that Gmail is probably the account recovery email, even if the passwords stored in the password manager.)
It got me to go through my accounts and delete the 5 or so password that managed to get into that manager over the years.
I consider my Google account to be very high priority in terms of keeping the login secure. Accordingly, I would never log into it on a remote machine like that. I keep APP on, and I'm not sure if I even could, what with the security key requirements. But such a remote machine is IMO always just too vulnerable to various types of compromise. One of the reasons I still have a Google account, for all of their faults, is that I think they're the best in the industry for blocking account takeover attempts.
Article OP didn't say why he felt the need to log into his Google account on a remote server meant for CI builds and with relatively low security. I think that would be the first point to address. There's just too many ways to compromise things once you make that mistake, and I wouldn't want to count on all of the other security bits being just right for an attacker not to be able to escalate that kind of access somehow.
Usually Chrome prompts me to enter my windows pin before showing me my password. The attacker also needs to know my Windows pin/pass to see those passwords.