1

While discussing alternatives for asking the browser to remember your password, one guy suggested using a bookmarklet to store users' credentials. The original answer is in portuguese, but I'll translate here the protocol he used:

  1. The user, while logged in, has access to a bookmarklet [link] with a unique token

  2. He can drag that bookmarklet to the links bar or to the bookmarks normally

  3. When clicking in that bookmarklet, the token is stored in the property window.name and a URL is loaded

  4. This URL contains a JS with another unique token

  5. The JS merges both tokens and creates a [authentication] hash

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

A bit more convoluted than necessary IMHO, but the basic idea was saving the credentials in the favorites bar, so the user could load the site and be automatically logged in just by clicking a single link.

I'm trying to wrap my head around the implications of such practice. I'm assuming it's safe against XSS at the very least (since JavaScript code can not access the favorites bar by any means AFAIK). And compared to stored passwords in the browser, it does not seem too far off (both would allow another person with physical access to the machine to log on as that user easily). Unless there's something else I'm overlooking...

Additional Info: My original intent was to keep (not necessarily store) in the browser some data that not even the server can access (for instance a client-side encryption key). This detail is important, otherwise this scenario would be no different from a "Remember Me" feature. But please don't focus too much on the specifics (I've discussed them at length both in this site and elsewhere), only on what was asked.

In other words, assume my thread model puts more emphasis in the confidentiality of the data in the cloud, and less in the user's client computer (e.g. someone with local access seeing the password is not a concern, but a XSS vulnerability leaking it would be). And ease of use is a requirement, otherwise nobody will use my system (more secure alternatives like using a password manager or browser extension that interact with PGP or even - in the future - the WebCrypto API will be offered to the more security-minded users, but not mandated; I asked the question to understand better the implications of using bookmarklets/the favorites bar, not to base my whole decision on it alone).

Community
  • 1
mgibsonbr
  • 2,905
  • 2
  • 20
  • 35
  • 1
    One thing you can do is store the secret in an iframe of a page you trust. This can be done with the postMessage api if you are careful to not leave any residue behind –  Jan 30 '14 at 20:39
  • @Rell3oT Do you mean, storing it on a cookie from a trusted domain? I **do** have a trusted server (the one that provides the JavaScript code - or else this whole client-side encryption thing would be pretty pointless...), in fact the main page is in the context of that server (the "less-than-trusted" storage server is the one that needs sandboxing), so no need to mess with `postMessage` (maybe except to transmit the authentication key - that the storage server will receive anyway). Your suggestion does not answer the question, but is indeed very helpful in my particular case! – mgibsonbr Jan 30 '14 at 21:01
  • I mean create an iframe of trusted site and use post message api to send it the secret. It sits at the other side listening. This isn't a great solution because there is a race condition between you and the attacker sending the post message (there are solutions, however) but the iframe will guarantee your secret is safe which your question was about –  Jan 30 '14 at 22:05
  • @Rell3oT Sorry, I don't understand what you mean. The purpose behind "storing" some data is that it should still be there next time the system is started. So suppose I send the data to the iframe to be stored, what will the iframe do with it? Send to the server? That would require me to authenticate with **that server**, so I'm just moving the problem elsewhere, not solving it... But if that iframe stores it in a cookie, then it will be available [in the same browser] even after a restart, until the user clears his cookies of course. That's how I interpreted your suggestion. – mgibsonbr Jan 30 '14 at 22:26
  • Won't it be stored in the bookmarklet each time it is ran? Nevermind I guess I just do not understand the question –  Jan 31 '14 at 00:28
  • @Rell3oT oh, sorry for the confusion! You were commenting on the suggested protocol, right? I thought you were suggesting an **alternative** to using bookmarklets... The intent here was to: a) when a password is **defined**, create a bookmarklet link [in the client itself] and drag it to the favorites bar; b) when the user wants to log in again, just click in the bookmarklet and the browser will load the page **and** provide the login credentials. However, the protocol is here just to frame the question - which is really about "the act of storing credentials in the favorites bar". – mgibsonbr Jan 31 '14 at 03:41
  • BTW I'm not a native english speaker, forgive me if I wasn't clear enough – mgibsonbr Jan 31 '14 at 03:42

1 Answers1

2

You shouldn't store sensitive data in bookmarks because people will not expect you to and they will therefore not treat the sensitive data appropriately.

Essentially it is no different to the "remember my password" option provided by the browser or the OSX Keychain, except it is less protected, and the user and their systems administrators may not understand that the need to protect it.

IE's "remember my password" is protected by DPAPI. OSX KeyChain is similar. KeePass requires an additional password. That's why they are "more protected". But the main point is people know those contain sensitive data and they will typically be treated appropriately by the administrators of the system.

But a bookmark is just a bookmark, right? Nothing sensitive about that is there? Sync & Share it all you like, right?

You should allow the user to use the appropriate keychain/password safe software for the system they are on. I.e. just let the browser "remember" the password if they wish, use OSX KeyChain, KDE's KWallet, Gnome's GnomeKeyring, KeePass and so on.

Ben
  • 3,697
  • 1
  • 18
  • 24
  • 2
    "the user and their systems administrators may not understand that the need to protect it" Very good point! About using password managers, I'll surely support it in my system, it's a lot better than the alternatives (saving in the clear, remembering a weak password, reusing passwords). However, that's beside the point of the question... (i.e. you **assert** that it's less protected, but don't provide any arguments to support it) In any case, if the OSes are providing better and better suport for properly protected passwords, then soon my question may become moot. – mgibsonbr Jan 30 '14 at 16:04
  • 1
    @mgibsonbr, expanded. – Ben Jan 30 '14 at 19:54