Can the browser "remember" a password programmatically?

Asked

Viewed 3,608 times

31

I am developing an application where from a password provided by the user a pair of keys (authentication and encryption) is derived. The password itself is never sent to the server, only the authentication key*.

I would like to offer the user the option to "remember" his password**. It is possible to do this, via Javascript, and in a secure way?

I read several references (for example, this question in the SOEN) and apparently there is no consistent way between the various browsers (e.g.: Chrome only offers to save the password in the return the submission of the form, and only if the password itself has been submitted - which is not the case here, because the password should never leave the browser). I am looking for alternatives.

  1. It is possible to "force" the browser to save a field password arbitrary, with the same level of security that it would save a password submitted? (yet that security not so high...) Preferably, satisfying this additional restriction of not sending it to the server.

  2. If you can’t save along with passwords, would there be an "equally good" solution? I considered for example the option to use localStorage, despite the emphatic warnings that "confidential information should not be stored in the localStorage". However, I don’t see how using it can be worse than saving the password in the browser - since someone with local access to the computer can also read these passwords... The only drawback I see is that it is more vulnerable to XSS - which I believe is not necessarily the case with the saved passwords in the "normal" way, without involving Javascript (or am I mistaken?).

    • Note: I know the Webcrypto API being developed. In the future - when it is consolidated and widely supported - it may become the ideal solution. However, I’m looking at short-term alternatives.

* and not the cryptography: all encryption takes place on the client side, so that not even the server has access to the user’s data; for this reason, the original password must be kept confidential inclusive server. More details [of my particular case] here.

** Assume as premise that the user has chosen to store the password. I am aware that this is a tradeoff security vs. convenience, and would like to offer different user options on this - instead of impose to him. An in-depth discussion on security would be off-topic here (more appropriate for security SE. for example), this question refers only to a problem of programming: command the browser to save a password through its usual mechanisms.

Updating: by "popular demand", here goes my Threat model ("threat model") and other particular requirements.

  1. The main concern is cloud confidentiality; that is, even if the code of my application (Javascript) must necessarily come from a reliable source (otherwise nothing I did would guarantee security), the server where the data are stored is "less-than-reliable" (i.e. there is the interest to "hide" the information confidential even of it - although it is not presumed malice a priori).

  2. Resistance against unauthorised local access is not a concern; it is assumed that anyone with physical access to the machine is authorized to access this data (and if, for a particular user, this is not true, he will be instructed to not save your password that way).

  3. To ease of use is a requirement of utmost importance; install plugins (Java, Webpg, etc.), password managers (Lastpass, Keepass, etc.), use a browser or particular OS (many have native integration with secure "keyrings") or even a server proxy location may be offered as option for the most conscious individuals in safety, but should not be obligatory: the system must be usable only with native browser features, platform independent.

I am posting this here because I have received too many suggestions to "don’t do it" or "do it instead", but my original question is not about security, and yes programming: whether or not it is possible to use the native mechanism of browser to "remember passwords" (each one has one, but the functionality is equivalent) programmatically.

javascript authentication security-guard passwords

  • Why not use SSL? http://cweiske.de/tagebuch/ssl-client-certificates.htm

  • @Ernandes Dar a option user use certificates on the client side may be a good idea, but I don’t intend to make it mandatory. I would prefer that access be possible only with something that the user know (i.e. he doesn’t need to be possession of something - in case the certificate file - to access the system).

  • Access via HTTPS does not require a certificate on client. As long as the password is not sent in a parameter GET, what would be the concern with the security of the information transmitted?

  • 1

    @utluiz (I don’t know if your comment is directed to me or Ernandes, but I will answer) My question is not about the safety of communicating - it will use SSL/TSL, and the authentication key will be passed via POST - but on the safety of data stored in the browser. If the user choose by the browser remember your password (by the way, the question also is not about "remember the session") it takes the risks that this entails (i.e. who has local access to the machine could recover this password). And certificates in the client are a good alternative, but the question is about passwords.

  • It would not be possible to use cookies to store the password value (if it is a problem to store the password in plaintext, encrypt it to save and decrypt it when you receive it from cookies) and load the password in the onload page?

  • @And with what key would I cipher? The problem is, if I had a safe way to store a key like this, I could simply use this way to store the password itself... (without having to mess with cookies)

  • Actually, I hadn’t thought about it, but using php, the key might as well be on the server side, right? It may be a misguided suggestion, but it is a way (the only one I can think of now) to solve your problem.

  • @Felipe.Avelar The problem is that if the key was on the server, the server could decrypt the password. The reason you use client-side encryption is because even the server doesn’t have access to your data. (in the question, I mentioned that two keys were generated, but authentication only was sent to the server; I will edit the question to give more emphasis to this fact)

  • 1

    Huuum, tendi, well I don’t know if it’s a possible solution for you, but a system passwordless would not be ideal in this case? It is still possible to see more information here and here.

  • 1

    @Felipe.Velar In fact, it is not a possible solution for me, but it is an interesting technique - that I have not yet known - and can serve me well in other contexts. This one doesn’t work because you still need to keep the encryption key offline... i.e. the server doesn’t know it, so you can’t include it in the link sent by email; and anyway, this solution assumes that the email provider is reliable (which in practice is a frequent premise). Often this is "good enough", but in my case I do not intend to use email as fallback (either authentication or encryption).

  • @downvoter If there’s something wrong with this question, please leave a comment so it can be improved...

  • @mgibsonbr, a very important thing (fundamental?) when we think of "safety", and which I am missing in the question (and the discussion in the comments), is a clear definition of the "Threat model". The Threat model definition allows both you and the people who will try to answer your question to better understand what your "fears", what attack vectors you want to protect yourself from, etc. Ex: Your system must be resistant to Eavesdropping? And MITM? And XSS? What about local access? What about Extensions? Without the answers, it’s difficult to propose a good solution.

  • @Brunoreis When I asked this question here, I wanted to keep the scope limited to a simple programming question, very objective. All this stuff you said is important, but I would choose to have this discussion on security SE. instead of here. Not that the question - if well formulated - is not on-topic on this site (it is a little wider than the OS in English), but the focus of this site is another, and the "experts" that it attracts are others. I admit that I was a little unhappy when I asked for alternatives, I should have limited to the default behavior of the browser, only.

  • I want to reinforce something important to evaluate this question: http://meta.pt.stackoverflow.com/questions/1/aqui-no-stackoverflow-com

  • @mgibsonbr Does this OS(en) thread help you? Have you looked there? http://stackoverflow.com/questions/2382329/how-can-i-get-browser-to-prompt-to-save-password

  • @Luizvieira Thanks for the suggestion, but I had already posted this link myself in the question: "I read several references (for example, this question in SOEN) ..."

  • @mgibsonbr Oops. It was mals. :)

  • I will still answer that question.... kkkk @mgibsonbr

Show 13 more comments

5 answers

9

I developed a practical solution a while ago, which is in use, consisting of the following:

  1. The logged-in user has access to a bookmarklet with a single token

  2. It can drag this bookmarklet to the link bar or bookmarks normally

  3. By clicking this bookmarklet, it stores the token in the window.name property and loads a certain URL

  4. This URL contains a JS also with single token

  5. JS merges the 2 tokens and does the hash

  6. The user is redirected to another URL with the hash as a parameter

Note that the bookmarklet token never travels open, only the hash resultant.

How the server has the hash of the user’s bookmarklets, just revoke in the control panel the pre-existing tokens if there is a mistrust of misuse, in case you want to force the user to reinstall an updated bookmarklet.

  • I never thought about it, keeping confidential information in the favorite bar... I did some research on this, and it seems to me that it is safe against XSS (bookmarks are inaccessible to Javascript code). I would not like to encourage users to use bookmarklets, as they are inherently insecure, but this would be a case where a good use of them can improve a system’s security. I will carefully evaluate this suggestion (maybe open a question on security SE.)

  • 3

    I developed this precisely for a situation where the access to the application would have to be very easy, because the constant login would be a very great discouragement for regular use of the same, given the need to annotate and quickly recover information in the system. I tried several other things and nothing pleased, and as it would have to be multi-browser, this was the most interesting exit. It has a small IE constraint on dragging bookmarklets, but is "circumventable". In the other browsers tested it worked well (FF,Opera,Chrome/Iron).

  • I was really interested in this idea, and ended up posting a question on security.SE. Let’s see what they say. But in advance: you remembered clean up the window.name after the hash has been computed? This is important, otherwise it runs the risk of being exposed if the user uses the back button of the navigator... (and indeed there are attacks that exploit this possibility)

  • 2

    Anyway it wouldn’t do much good, because the window.name alone is not enough to log in, it has the server hash that is unique by login, and it would not be possible to reuse. But it’s clean, yes, to prevent a third-party URL from accessing it (but just as a curiosity, you should imagine how unlikely it would be for someone to be able to repurpose that window in a "contaminated" URL :) )

  • Hehe did you get to try the link in my last comment? Maybe it needed some "social engineering," yes, but I don’t think it’s so unlikely that the attacker could get the victim to open the site in a tab apparently empty, but in fact the attacker controls. (but this combining the saved token with a single token from the server seems to me an appropriate defense)

1

Anything stored in the browser could be targeted by an XSS in some way. And each browser will have its own method of storing fields (such as password or encryption key), which makes a universal solution difficult.

You could then use a small program on JNLP / Java web start. This way, the user would be running a program on your machine, without having contact with the server, but without the difficulties of installing the program, etc. If you sign the program or show the user how to properly configure the access levels, this "password" symmetric encryption could be stored on the user’s local computer, including encrypted with some other key that your java program will use.

  • "Anything that is stored in the browser may be targeted by an XSS, somehow" not that it solves my case, but a cookie HTTP-ONLY could not be captured via Javascript, no? Anyway, I liked your suggestion, it does not answer directly to the question (I would prefer something that is natively supported by the browser) but it is an interesting idea to consider - develop a "security module" for my application.

  • @mgibsonbr has achieved a solution?

-1

Simple.

This type of info was previously stored in cookies but now with the new versions Html5 of browser you can save everything using LOCAL STORAGE.

In the same way that the bitcoin blockchain site stores everything encrypted in the user’s own browser, so nothing gets saved server side.

Attention this site http://blockchain.info is the most used as bitcoin Wallet and responsible for hundreds and hundreds of thousands of euros in Bitcoins of almost 1 million users.

All done with localStorage... I THINK YOU CAN TRUST :)

More info how to use Storage site:

http://www.w3schools.com/html/html5_webstorage.asp

  • 2

    Thanks for the suggestion, but as I quoted in the question, the warnings of the OWASP on the site Torage left me with the flea behind the ear... By the way, the blockchain.info does not store passwords on site Storage: "No sensitive data is stored in your browser’s local Storage. If available the site will cache your Wallet Identifier, address balances and transactions, in the Event of login with a Different Identifier this data is cleared."

  • It really doesn’t store the password itself. It only stores Identifier and other data.. Da to query on the Chrome console. What you can store is an encrypted version of the pass that is sent to the server and with php decrypts a pass, if it’s the same, it authorizes Session. Or use the old cookie system.

  • 3

    Saving "an encrypted version" of the password is equivalent to saving the password to plaintext: because if the server is going to decipher, then the ciphertext is the credential - it doesn’t matter if we call it a "password" or something else (e.g.: If an attacker has access to CT, he simply sends it to the server and is authenticated). I mean, I’m not saying that encrypting "makes things worse," simply that the cipher is redundant (using or not using makes no difference if done that way).

-1

I think the best solution for this is not do. Just read the title once to know that it tends to go wrong. The moment you can think of something, implement it and put it on the air, when someone who is "attacker" realizes that this functionality exists on your system, and that it is not recorded in the browser, he will be very curious, will study and try to understand what you have done. He will find out, they always find out. Security through obscurity is not the best way.

And now let’s think on the user side, what good does it do him? Let me think... I already know! He will click login and will login. Ease is a cool thing. Only it becomes a convenience, and soon, it will soon forget the password. And if at some point he needs to use the password, what will happen? Password reset. A long way from facilities, to arrive at a password reset. This happens in banks, they use other means of access to your account(fingerprint, letters), and the moment you need the password, you do not remember. And why? Why don’t you use.

I think you better stop and think if this is really a good thing.

  • 1
    1. My project is open source, anyone can see the sources... "Security by obscurity" would be if I tried to hide the algorithm. But an algorithm can be public and yet safe (what has to be secret is the key). 2) A typical user has dozens of accounts in different services. Does it create a distinct, strong password in each of them? No, it reuse the password or notes somewhere. If I offer him a minimally secure means of storing the password, despite all the regrets, that’s a step forward. And he won’t have to reset ever - because the password is there, saved.

  • P.S. I’m not saying saving passwords is always a good thing. It’s not, and more mindful users won’t do it. But in my experience - corroborated by the opinion of most security experts - there is no point in trying to "force" the user to adopt an inconvenient behavior in the name of security. There comes a point where users begin to actively "fight the system". In other words, "security only works if it’s easy"...

-1

Your main question is where to store?

With the security you want to implement, it would be interesting to store?

Let’s go in pieces.

Storage that we have today in browsers are all XSS-capable. The only possibility I see would be a JAWS application (as woliveirajr said), but even that application would be able to keep the storage intact?

For the solution you are mounting I believe that removing the option to "store" would be the most interesting, force the user to always log in. Imagine a bank or a homebroker using this technology, leaving the responsibility of storing the "password" on the user’s machine.

  • Unfortunately, "force the user to always log in" may be the same as "make users no longer use my system"... I’m thinking of something else "low profile" what banks or things like that (although my intention is to build a platform, not a specific application, so it is not in my control how exactly it will be used). I reiterate what I said in the comment to Jodson Leandro’s reply, "security only works if it’s easy". And depending on the Threat model, local access to the customer’s computer may not be a concern, but cloud confidentiality yes.

  • Maybe you can use the cookie Httponly setting a key that will be recovered by validating along with the key received from JS.

  • Ih, an Httponly cookie is basically the other way around what I’m looking for: something the server sees, but Javascript doesn’t see... (what I want is something Javascript sees but the server doesn’t see) Httponly is very good for "remembering the session", but not so much for "remembering the password".

Browser other questions tagged javascript authentication security-guard passwords

You are not signed in. Login or sign up in order to post.