Password entry: are “paste from password manager” and “eyeball to view passwords” mutually-exclusive features?


NIST SP 800-63b gives the following guidance for password forms (aka login pages):

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

I had the argument made to me that these two features should not be implemented together because they would allow a user to circumvent a password manager’s protection and view the auto-populated password. I suspect this argument won’t hold water, but I’m curious about community opinions.

MySQL password rotation: Using a single user to change other user passwords

I’m currently working on setting up a password rotation strategy for an AWS Aurora/MySQL based application.

My plan was to use a strategy like this…

  • Application usernames/passwords stored in AWS SSM encrypted parameters.
  • Application servers have access to retrieve only their credentials from SSM. Restricted by environment (staging, production etc.)
  • Lambda configured to run periodically to change passwords in MySQL and store the new values in SSM. Lambda to authenticate with the database using AWS IAM roles, rather than using a password.

The last bit is the bit I’m not sure about. This configuration would require the lambda role/user to have permission to change the passwords for all of the other application users.

Is this a reasonable way to do it, from a security perspective? Since the lambda mysql user will use an IAM role rather than a password, this should retrict it’s use to only authorised roles.

The alternative would be to not have a special db user for the lambda to login, but rather to have the lambda function retreive each users credentials from SSM, and then login as each user to change it’s password.

Either way the lambda is going to need to have access to each user.

Assuming I can carefully retrieve access to the "lambda_user" in MySQL, are there any other glaring issues with having a user have authority to change other users passwords?

Also, just to clarify, these are application users, not regular human type users who will be using these credentials.

Is using Argon2 with a public random on client side a good idea to protect passwords in transit?

Not sure if things belongs in Crypto SE or here but anyway:

I’m building an app and I’m trying to decide whatever is secure to protect user passwords in transit, in addition to TLS we already have.

In server side, we already have bcrypt properly implemented and takes the password as an opaque string, salts and peppers it, and compares/adds to the database.

Even though SSL is deemed secure, I want to stay at the "server never sees plaintext" and "prevent MiTM eavesdropping from sniffing plaintext passwords" side of things. I know this approach doesn’t change anything about authenticating, anyone with whatever hash they sniff can still login, my concern is to protect users’ plaintext passwords before leaving their device.

I think Argon2 is the go-to option here normally but I can’t have a salt with this approach. If I have a random salt at client side that changes every time I hash my plaintext password, because my server just accepts the password as an opaque string, I can’t authenticate. Because of my requirements, I can’t have a deterministic "salt" (not sure if that can even be called a salt in this case) either (e.g. if I used user ID, I don’t have it while registering, I can’t use username or email either because there are places that I don’t have access to them while resetting password etc.) so my only option is using a static key baked into the client. I’m not after security by obscurity by baking a key into the client, I’m just trying to make it harder for an attacker to utilize a hash table for plain text passwords. I think it’s still a better practice than sending the password in plaintext or using no "salt" at all, but I’m not sure.

Bottomline: Compared to sending passwords in plaintext (which is sent over TLS anyway but to mitigate against server seeing plaintext passwords and against MiTM with fake certificates), is that okay to use Argon2 with a public but random value as "salt" to hash passwords, to protect user passwords in transit? Or am I doing something terribly wrong?

How do I minimize the number of passwords leaked when a PC gets compromized?

For customer support reasons, we need to store passwords to some of our customers’ systems (with their explicit, written permission, of course), as well as, obviously, passwords to some of our own systems. Customer support agents and administrators need to be able to access those passwords.

I am aware that – despite all our efforts to the contrary – it might only be a matter of time before one of the PCs in my company’s network gets infected with malware.¹ When that happens, I want to minimize the damage. In particular, I want to minimize the number of passwords that gets leaked.

Classic password managers don’t help here. They help against password reuse and other dangers, but they are not designed to mitigate that kind of threat. On the contrary: The customer support guy’s PC is compromised, they enter the master password to their password manager and… bang… the bad guys have won the jackpot.

I am looking for a solution to ensure that only as few passwords as possible (ideally, only the passwords actively used during the time period between the PC being compromised and the attack being detected) are leaked.

Obviously, storing the passwords on paper² instead of a password manager would solve this, but I would also like for the solution to be practical (the paper solution won’t work if the users are in pandemic-induced home office, for example). Another option might be an online password manager which "rate limits" the number of passwords that can be accessed per hour (and sends out e-mail alerts when too many password are requested).

I don’t want to reinvent the wheel, and I’m sure that other companies have the same issue. Is there any "canonical" or at least widely-used and established solution to this issue?

¹ If you google for "percentage of companies having been hacked" or "percentage of companies having been infected with malware", you get various news articles on the first page claiming various two-digit percentage rates. I don’t want to get hung up on a particular number, I just want want to illustrate that the risk is real and much, much more likely than "rubber hosing" or something similar.

² To clarify the threat model: I am concerned about hackers on the other side of the world having a "lucky day" (i.e., an employee starting a malicious file which somehow managed to get through all our filters), getting into our network and then seeing what they can harvest before doing their usual ransomware stuff (yes, we do have backups). I am not concerned about targeted and/or physical attacks by state actors (fortunately, we are not important enough, and neither are our customers).

How do very big companies manage passwords?

Third-party password managers such as 1password, etc. are very useful for people, businesses, etc. to store passwords, but obviously I bet Facebook, Google, Twitter and other super big tech companies don’t use such third-party services and have their own password managers for their most critical passwords.

How can a very big company manage some of the world’s most sensitive passwords? (example: Gmail team root access password!)

Even with the most advanced password manager, you still have the problem of the master password.

Should this be shared among a few trusted people? Or kept by only 1 or 2 people (then what happens in the case of an accident?)

Are big companies known to use implementations of Shamir’s Secret Sharing?

More generally, what are well known methods that very big companies use to manage their most sensitive passwords? (i.e. passwords that, if lost, could generate tens of billions of $ of loss)

is bcrypt(strtolower(hex(md5(pass)))) ok for storing passwords?

I have a large database where passwords are stored as strtolower(hex(md5(pass))) (which is a bad way to store passwords, prone to rainbow tables, cheap to dictionary attack, no salt, etc), and I’m tasked with switching from md5 to bcrypt,

I have to use a bcrypt implementation that silently truncates after 72 bytes, and silently truncates on the first null byte (whichever comes first), and bcrypt(strtolower(hex(md5(pass)))) would not be prone to either of those issues.

Also it’s possible to retroactively apply bcrypt to existing strtolower(hex(md5(pass))) password hashes, without requiring everyone to re-login/switch passwords.

Is it a bad idea? I don’t think so, but still want to hear what security.SE has to say. Maybe there is something important I’m missing.

Cowrie (Honeypot) to not store passwords for certain username entries [closed]

I have a honeypot setup on port 22 (using "cowrie"). I need certain usernames to be logged without passwords. So if someone logs in with the username "jack" and the password "passw0rd", it will only not log the password while if someone were to login with "harvey" and the password "password" it will log the harvey’s username and password.

Server (please complete the following information):  OS: NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)"  Python: Python 2.7.5