Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)
Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.
Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.
This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.
And I store my DB in Dropbox, but not the key.
The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.
I also have some measures in place to detect. (Ex: hard coded lists of URLs that open in a "financial" container)
I don't claim it's perfect, but it's my way of doing things, I like it, and I don't think it opens me up to an unreasonable amount of risk.
(Also, for lower-value passwords, like netflix, HN, etc I just use my browser's built in password manager.)
With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).
I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?
You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.
I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!
Very very hard for you to prevent copy/paste to a fake iframe SSO.
So the intention is that I stop some script from siphoning my passwords.
This admittedly opens me up to phishing, but to mitigate I also have containers set up for various facets of my life.
(So it's a big red flag if what's supposedly my bank doesn't open in the "bank" container".)
Edit: I also value storing the database locally versus "in the cloud"
/s
I actually can't imagine how it could be safer than having the password manager do it directly.
If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here.
If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password manager is irrelevant [1]. Instead there is a bigger issue needing cleaning up, that of returning the local system to a trustworthy state.
[1] because an untrustworthy local system running clipboard sniffing malware is also likely running key logging malware, so even if the passwords were only ever memorized they will still get captured whenever they are typed in.
- user copy-and-pastes password
- user forgets to clear clipboard
- user opens a link in a new tab with middle-click
- link was actually a text form
- middle-click pasted the password into the textfield
I noticed this when I had an image url in my clipboard and tried on open a link on imgur.com in a new tab. Instead of opening the link, the image url in my clipboard was uploaded.