I want to display some very sensitive information on a web page and I want to make sure that nobody, except the user in front of the browser, is able to access this information. I'm aware that in general is it not a good idea, but some site manage to do it. For example : LastPass

What are the security risk to consider?

How would you proceed to implement it securely?

Assume that the client computer is not compromised and that it's the client problem to be sure no on else is looking above his shoulder.

Now, if you are going to just reply "NO", just don't. It's clearly possible because some site are doing it or are you saying that they are all unsafe? If this is the case, could you please elaborate?

And, before anyone flag this question as duplicate, I just asked the same thing here but it didn't receive any good answer and the question was put on hold, maybe because I didn't formulate the question correctly.

Also, if anything is not clear in the question, please leave a comment below and I will answer it.

  • 1
    It is unclear what you are trying to protect against. Trojans? Keyloggers? Man in the middle? Other people watching the same screen? Screenshotters?
    – Chris
    Jun 28, 2014 at 1:44

5 Answers 5


There is no magic way to safely display text on a webpage. Either it is safe to display or it isn't, and which of those buckets your data falls into depends on your threat model. What specific threat are you wanting to protect against, and what is the risk of the threat being utilized in an attack? To counter the risk, what is the value of displaying the data to the user? Is it important enough that they see the data that the value outweighs the risk?

In the case of LassPass, the entire application is designed to allow you to manage passwords. Sometimes that means you need to see the passwords in plain-text. It's an important feature of the app, and thus, worth the risk of a shoulder-surfer discovering the password. For most other applications, there's not really much value in displaying a plain-text password to the user, so displaying it wouldn't offset even small risks.

So, you have to decide for your use case is the value of displaying the data to the user greater than the risk, or not?

Beyond this, it's worth mentioning that there is a third way. You could leave it up to the user. You could ask them (via a checkbox, or a link, for instance) if they want the data to be displayed. Then it's up to them to determine if the value of seeing the data outweighs not only the general risk, but the specific risk at that instant. (They might choose differently if using a computer at home vs. a kiosk in a crowded mall, for instance.) So you could default to the safer option of not making the data display, but give the user the option to override that default. Realistically though, there needs to be significant value in displaying the data for you to even display it at all. Generally in the specific case of displaying a user's password in plain-text, that value simply doesn't exist.

  • I would add that there is a theoretical risk with the page being cached (on disk), and other users being able to access the information that way. To mitigate that risk, the site would need to add certain no-cache/no-store headers.
    – Joel L
    Jun 28, 2014 at 20:23
  • @JoelL That's a good point.
    – Xander
    Jun 28, 2014 at 20:47

If you really don't want anyone but the 'user in front of the browser' to have access you need to encrypt the data at rest (server side) as well as the communication channel (HTTPS). You would need to have some kind of decryption algorithm implemented client side.

For details see https://webapps.stackexchange.com/questions/11361/how-does-lastpass-store-my-passwords-on-their-website.

The same model would be applicable here.

  • Yeah, basically like secure notes, encrypt it by the user's hashed(and stretched) password before saving it remotely. At this point I don't know if https is necessary, the data is secured by your password, not ssl. Jun 27, 2014 at 16:31
  • @AndrewHoffman true but that doesn't cover getting your authentication securely to the server... If someone gets your authentication token you now have someone else with access. I suppose I could have clarified that a bit. Jun 27, 2014 at 16:33
  • yeah I understood you, just saying for non-http stuff like sms or whatever, clientside encryption would be enough Jun 27, 2014 at 16:40

Using SSL, requiring that the entire page be SSL and authenticating the user during the session ensures that only the browser that the user is using has access to the data, but you have no way to ensure that there is not software on the user's computer that is copying the data away, nor is it really your responsibility to ensure the integrity of the client's computer in most cases.

Web sites have almost no control over the client environment, so you are forced to trust that the browser the user is using is secure and will behave properly.


There is absolutely no way that you, the website owner, can ensure that only the user can view anything that your website displays to them. The user is an entity entirely beyond your control and, in most cases, they're viewing your site on a system that is almost equally beyond your control.

The security of information displayed on a web page, once it reaches the user's computer, is entirely dependent upon the security of the user's computer and the environment in which it and its peripherals reside. There is no way you, as a website owner, can fully control this.

The best that you can do is to secure the data on your own systems, and implement strong encryption and authentication mechanisms to ensure that only authorized users will be able to retrieve that data remotely. Once the data is in the user's environment, its security is no longer under your control nor should it be considered your responsibility so long as you can prove that you and/or your system were authorized to provide the data to the user at the time it was provided.


There are three approaches to this problem:

  • You encrypt the sensitive data on your server and decrypt it on request. This is what Lavabit did, and it didn't end well. The problem is that no matter how much crypto voodoo you do, the entire security always depends on your server. Your service will be just as vulnerable to attacks as any other standard website.

  • You delegate the cryptography to the client, but you do provide the tools. For example, you include a JavaScript program on your site which encrypts the data before its sent to the server and decrypts the encrypted data coming from the server. This may sound like a good idea, but it's really just the first option in disguise. The security of the data still depends on your server. An attacker who's in control of the server may be able to simply break the tools and subvert the encryption.

  • You keep your hands off the data and the encryption and leave everything to the client. In other words, you only deal with encrypted data and don't even know the plaintext. This is really the only honest solution. However, it means that the users need additional tools like PGP/GPG. This might be a problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .