If you're on Mac OS, there's a nice little app I use to bypass almost any mechanism of preventing pasting. It simply uses a virtual keyboard to type out the contents of your clipboard. http://dae.me/blog/1741/
[deleted]
Let them paste passwords
271–280 of 376 posts
Re: Let them paste passwords
#272Until password managers are ubiquitously integrated with mobile apps, we are forced to use the clipboard to transfer passwords. Unfortunately, any app can access the clipboard, revealing passwords. Copying passwords from 1password always feels dirty for this reason, and unfortunately I don't have a good solution to this problem.
Re: Let them paste passwords
#273Until password managers are ubiquitously integrated with mobile apps, we are forced to use the clipboard to transfer passwords. Unfortunately, any app can access the clipboard, revealing passwords. Copying passwords from 1password always feels dirty for this reason, and unfortunately I don't have a good solution to this problem.
On Android versions since Lollipop password managers don't need to use the clipboard. I think on iOS they still need to.
Re: Let them paste passwords
#274Until password managers are ubiquitously integrated with mobile apps, we are forced to use the clipboard to transfer passwords. Unfortunately, any app can access the clipboard, revealing passwords. Copying passwords from 1password always feels dirty for this reason, and unfortunately I don't have a good solution to this problem.
I've never used 1password, but Keepass2android registers as keyboard and types username/password.
Re: Let them paste passwords
#275Earlier quoted context omitted.
> your password can't be anything like any of the previous ones (i.e. they're not stored hashed) That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).
Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed. Developer: Similar passwords? Or Same passwords. Similar is hard. M: Similar. Can't let people be lazy with their passwords. D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but... M: Good! Let's do that. D: ...but that could be a massive amount…
Been there, fought that.
Re: Let them paste passwords
#276Earlier quoted context omitted.
> your password can't be anything like any of the previous ones (i.e. they're not stored hashed) That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).
Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed. Developer: Similar passwords? Or Same passwords. Similar is hard. M: Similar. Can't let people be lazy with their passwords. D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but... M: Good! Let's do that. D: ...but that could be a massive amount…
longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing
Re: Let them paste passwords
#277I agree with the premise. Though, there's one more issue/potential reason not to endorse people using the clipboard for passwords, and it's not that malware will grab them from the clipboard. It's that many non-malicious programs will regularly query the clipboard for legitimate reasons, but what they do with that data may be insecure. For example, think of how Pocket checks the macOS/iOS clipboard for URLs to add to the Pocket list.
Re: Let them paste passwords
#278Of course it reduces security. It makes you resort to either 1.) typing it out manually while you can't see if you made a mistake 2.) using developer tools to set the 'value' attribute directly "SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right mor…
Other signs that a site was built by incompetent developers (Or had too much management interference--Devs aren't always to blame!): Only works with Internet Explorer Doesn't work with Internet Explorer Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc) Passwords have no requirements Right-click is disabled Video play…
You think it's a cost thing ie what the server can compute....?
I forget the term I did this with openssl, Apache, I think with a cheap vps I get between 9 and 10 cost, bcrypt. Sorry if these are not directly related for hashing.
A few sites I have to use for my dishwashing job work ie. share point and a card company that manages my money, as well as another by WalMart, they don't allow special characters only upper case-lower case and digits. You'd think okay length then but some have limits like a 15char limit.
Re: Let them paste passwords
#279Earlier quoted context omitted.
Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed. Developer: Similar passwords? Or Same passwords. Similar is hard. M: Similar. Can't let people be lazy with their passwords. D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but... M: Good! Let's do that. D: ...but that could be a massive amount…
longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing
But a longer password would require more combinations for similarity than a short password.
Re: Let them paste passwords
#280Earlier quoted context omitted.
Think of it this way: passwords are a more standard API than OpenID. Since passwords are the standard, they are "implemented" by all your clients. That cannot be said for OpenID.
I'm not suggesting "don't implement passwords" (which are first-party authentication) or "don't support password pasting" (which mainly supports ad hoc third-party authentication with a manual token exchange), but if you are actively choosing to support pasting (and, thus, third-party SSO with a clumsy UI), you should also strongly consider supporting third-party authentication with a decent UI.
The password manager solution is, if you'll allow me to strain your analogy a bit, "second-party SSO". That is, it's SSO that I, the user, manage however I prefer. Password pasting is an extensible API for achieving that.
But we don't disagree, folks should definitely implement things like OpenID.