CODEWITHSUNDEEP
securitypassword-policy
Ralph Shillington
Ralph Shillington

Reputation: 21098

Returning a password to the web user

I have received the unfortunate requirement of building a page that displays a new password to the authenticated user. I have unsuccessfully protested this requirement as a generally bad idea, but I think the jury is still out so perhaps there are arguments against displaying a new password that I haven't tried yet. Do you have any suggestions?

Second, would it be better to display the password to the user as an image, rather than as text. I'm concerned about the text being "scraped" which I'm assuming would be more difficult with an image. How do I make sure that the image will not be cached by the users browser?

thanks in advance,

Upvotes: 1

Views: 250

Answers (5)

SilentGhost
SilentGhost

Reputation: 319821

did you try the following?

  • you cannot show password because you don't store it.

Upvotes: 3

Kevin Ji
Kevin Ji

Reputation: 10499

I simply suggest using HTTPS to encrypt traffic and storing only hashes of temporary passwords, so that the actual password is not stored within the database. Of course, you cannot prevent physical "hackers" (such as people looking behind-the-shoulder) from stealing a temporary password, but, if possible, you can require users to change their password the instant they log in with a temporary password, so that the risks with a temporary password are mitigated.

Upvotes: 0

Daniel Brückner
Daniel Brückner

Reputation: 59675

I am not sure if it is really such an bad idea. You have to send the new password to the user in either way. Sending as unencrypted email has the same issues - beeing captured or beeing cached when using web mail.

I would suggest to use a image, may be some captcha like one. But this protects only a bit more against automated attacks, not against human attacks.

The only way to get the thing secure is to use enryption, suggesting HTTPS. Then using your website to display may become even more secure than relying on email or solutions like that.

Leting the user enter a new password has the same issue - now you have to send it back to the server.

Upvotes: 1

Guss
Guss

Reputation: 32354

I'm not sure what you are build and what is the requirements, but as a general rule of thumb I do not consider this a grievous security concern. Lets look at the attack vectors:

  1. Man in the middle attack on the HTTP text traffic - an image, especially one obfuscated against OCR (CAPTCHA style) will prevent this attack, but also simply using HTTPS as porneL mentioned.
  2. Screen scraping by a remote desktop application - HTTPS protection will not help, nor an image as the mess on a screen has to be read by a human anyway (a human attacker can also circumvent your obfuscated image protection against "man in the middle" by instructing the listener to archive the image and then go over them manually). If a human is behind the screen scraper, then you have no protection.
  3. over your shoulder eavesdropping - if the attacker is simply standing behind the user, then again - you have no protection.

Do note that if your password is autogenerated, then you must show it to the user, there is no way around that. One way sites try to mitigate the threat is to send the password by email - under the assumption that a user can make sure they read the email when no one is looking, at their own time. Unfortunately email will not even let you have the benefit of encryption to protect the transfer.

In my opinion, the best way is to let the user input the password (in a password obfuscation field, like normally it is done) and then only store the hash of the password so you need not store the actual password, preventing you from showing it to the user. If you must show it to the user (possibly because you are generating it), then make sure you are over HTTPS and just show it - all the fanfare just complicates the implementation without giving any security benefits.

Upvotes: 3

Kornel
Kornel

Reputation: 100170

Image will not secure much.

If you use HTTPS, then password will be secure either way. If you use HTTP, then password will be sent in clear text from the form (I assume you're displaying it for some kind of confirmation), and how it's displayed seconds later won't matter.

Important thing is to ensure that page that displays password is non-cache'able.

Cache-control: no-cache, no-store, must-revalidate

Upvotes: 4

Related Questions