Community
Participate
Working Groups
Orion should remember user credentials for git repository: password OR key+(optional)passphrase.
*** Bug 359889 has been marked as a duplicate of this bug. ***
I've been thinking a little about that requirement and it's hard one to meet. Generally passwords should never be stored on client site, it's because they would have to be encrypted with symmetric key and later on they could be read from your workstation, not necessary by you. Using sessionStorage would be somewhat safer. Your password is stored as long as your browser session in active, but is cleaned when you close the window. But, depending of your working style, it may not help you at all. I usually open GitLog or GitStatus only when I need it. I do a commit/push/fetch/merge and close the tab. When you open GitStatus again you would have to input credentials again. The best idea I could think of is to store credentials somewhere in secure storage on server. Credentials window would have a check "store my credentials" and if it was checked server would store your credentials on the server site. You could then go to user profile to clear the git passwords storage.
Something does not add up because browsers save passwords all of the time.
(In reply to comment #3) > Something does not add up because browsers save passwords all of the time. Yes, but they have their own storage that is secure. Also user may clear passwords in the browser any time or turn saving passwords off. What is more this is a common standard and most of the users know how to handle it. We would have to store passwords in some place reachable from javascript (localStorage, cookies) that would expose them for cross site scripting forgery. I've been google'ing for a good way to store passwords and all I found were suggestions not to. BTW storing passwords in a browser is not that secure as well, see this: http://www.raymond.cc/blog/archives/2007/07/11/how-to-find-hidden-passwords-in-firefox/
*** Bug 364584 has been marked as a duplicate of this bug. ***
This problem could be solved using asymmetric cryptography, e. g. RSA. Let us assume, the user wants to store his credentials at some point. Given these credentials, the client side generates two keys: a public, and a private one. The credentials would be encoded using the public key which is immediately dropped. The private key (for decoding) would be sent to the Orion server. The user stores his encoded credentials in a local file. The location of this file would be stored in the local storage (and also on the server side). Now, what happens if we want to push our changes to a remote? The Orion client looks into our settings in order to find the credential file location. If present, the file is POSTed to the server and there decoded (for further use). Otherwise, the Orion client asks the user for the file location or the credentials. This way, the credentials are stored locally in a encoded form. The server does not store any of our git credentials. Encoded credentials are easy to import/export through various machines and/or OS. The user is prompted for the credentials only if the file cannot be read, e. g. we changed our workstation. What if we work on different machines and/or browsers at around the same time? We could consider some "credential profiles" stored on the server side. We would store profile fingerprints in the local storage so the Orion server could dynamically switch between credential profiles based on our IP address, browser type, OS, etc. Of course this credential store idea would be disabled by default, but could be enabled any time in the user settings. Credential profiles could be changed and manually set by the user.
(In reply to comment #6) I would start from implementing the original idea discussed already in Bugzilla ie storing credentials in a file and just have its location in the local storage and the user profile on the server side. If the file is stored in the user space on hard drive or encoded USB key, this solution is safe enough by itself. Then you could work on encoding the file to prevent stealing credentials when someone somehow intercepts the file.
(In reply to comment #7) As I'm thinking of it right now, I see another reason why we should encrypt the credentials. POSTing credentials file via a XHR call would make them especially vulnerable to any sort of theft or forgery. Unfortunately, we cannot POST them so easily via https on a standard http connection, because of the "same origin policy". Maybe this could be solved using some iframe behavior, but even if so, it seems to me somewhat artificial.
(In reply to comment #8) > (In reply to comment #7) > As I'm thinking of it right now, I see another reason why we should encrypt the > credentials. POSTing credentials file via a XHR call would make them especially > vulnerable to any sort of theft or forgery. Unfortunately, we cannot POST them > so easily via https on a standard http connection, because of the "same origin > policy". Orion on eclipse.org or any other production version should use ssh. So you would not have to handle cross-domain issue. I'm not saying we should not encrypt credentials, I'm just saying let's just start from sending a private key and storing its location in the local storage and the user profile.
*** Bug 370582 has been marked as a duplicate of this bug. ***
Any positive/negative comments are mostly welcome. Mock functionality will be provided by bug 387094.
In response to the talk we had yesterday with Ken, John, Szymon and Gosia I'd like to describe some ideas on this feature and briefly comment on their advantages / disadvantages hoping to start a discussion which will end with a conclusion on how saving git credentials should work. Because introducing cryptography at this point is time-consuming and problematically, let's postpone it for a moment and focus on the user experience. The main idea is to automatically provide git credentials so the user doesn't have to. In this way a quick push operation 'costs' the user just 2 clicks ('push all' and 'OK' on the branch dialog) after the credentials are saved. Possible approaches on how to store the git credentials: 1. use session storage: (+) after we close the browser all credentials are erased. (-) depending on your workflow it might help you, or not. Session storage is a per-domain-per-tab solution. If you open a link by opening a new tab (common workflow) all the session storage is cleared in the new tab. Tested on Firefox. 2. use session cookies/cookies: (+) after we close the browser all credentials are erased. (+) data is available across all tabs from the same domain. (-) cookies do not allow any whitespaces in their value (which we need for the private key) 3. use native browser password storage: (+) our work is done by the browser (-) user would have to click on the 'more' option on the credentials slideout and then the 'OK/' button on the git credentials dialog. (-) we have no control over this mechanism. Each browser may have their own policy about how to determine when to suggest a password. I've found some heuristics when this mechanism works. Conclusion: this works on simple two-input forms with a special password input. Unfortunately, we have to use something more advanced than a simple form. If someone is interested here are some links on this manner: http://stackoverflow.com/questions/2398763/how-does-browser-know-when-to-prompt-user-to-save-password http://stackoverflow.com/questions/2382329/how-can-i-get-browser-to-prompt-to-save-password http://mxr.mozilla.org/firefox/source/toolkit/components/passwordmgr/src/nsLoginManager.js#626 (worth taking a look) 4. use persistent local storage: (+) it works (+) credentials are secure as long as the user account is secure (-) we need to inform the user that his/her credentials are stored persistently in the local storage. Seems a little cost to me, i. e. we could add a 'clear credentials' option in the settings. Also please notice that we need JavaScript access to the credentials on the client side. At the moment I'm not aware of any other possibilities. My favorite solution is the 4th one (and I'm currently working on it in bug 387878). If anyone has an alternative idea, please do not hesitate to post a comment. Any input is most welcome.
As a best practice we should never persistently "store" credentials in the client. Period. I am not at all confident that the browser provides a user space environment that is a safe place to store things like private keys. Most user's do not understand the consequences of storing credentials so even a really well written dialog telling them is not helpful and I imagine will be passed through with as much thought as many EULAs are. -- I would investigate the session approaches as we are not setup to manage persistent storage of this sort of material. 1)I agree the sessionStorage approach looks like its user experience will be only marginally better than what we have currently (but still better). 2) Whitespace is of course easily encoded but another approach might be to take a look at using a server-side servlet session as at least its lifetime is bound and under our control instead of sending sensitive cookies around. 3) The built-in browser way would be cool but certainly harder. Thanks for the links. Even if we don't use the built-in browser for git credentials I imagine having an understanding will be useful in other login contexts. 4) It may be the easiest approach but...
Orion won't be used for high security systems any time soon, no matter which solution is used. On the other hand, client-side attacks to gain git credentials seems very unlikely. The intrinsic value of a few git credentials is very low and the Orion server would be much richer target even if the git credentials had value. On the other hand using Orion for less than high security systems is hampered by the current non-solution.
(In reply to comment #13) > I am not at all confident that the browser provides a user > space environment that is a safe place to store things like private keys. Because there simply isn't one. That's why the safety part should be somehow managed by Orion. Please notice, that the git credentials are typically stored in the ./ssh folder in an PEM format (---BEGIN RSA PRIVATE KEY--- and so on) using a passphrase or not. In other words they are persistently stored on the client side in an encrypted form without the password to decrypt them (exactly like in our solution). Because we can trust the browser local storage domain security policy none but the Orion server has access to this private key. This seems to me fair enough in terms of security. > Most user's do not understand the consequences of storing credentials so > even a really well written dialog telling them is not helpful and I imagine > will be passed through with as much thought as many EULAs are. That's why we could disable this mechanism by default. Combined with my explanation above I strongly believe a simple inform dialog is enough since we use a mechanism similar to the PEM private key file. We simply copy this file from on location to another on the user disk. > 1)I agree the sessionStorage approach looks like its user experience will be > only marginally better than what we have currently (but still better). Forcing a workflow in order to enable a feature does not seem better to me, but I get your point. Please notice also, you'd have to inform the user how to work to get this feature actually working. This seems artificial since we should react to the user needs and not the other way around. > 2) Whitespace is of course easily encoded but another approach might be to > take a look at using a server-side servlet session as at least its lifetime > is bound and under our control instead of sending sensitive cookies around. I think a client-side solution is still better. Assume the server is somehow corrupted, e. g. was hacked. If we would store the credentials on the server side possibly all user data might be exposed to theft (or worse). I agree with John on this manner - client-side attacks are unlikely, hard to perform since we have the browser domain-local-storage policy, and even if successful the hacker will gain access to a single user git credentials, not all users on the server. > 3) The built-in browser way would be cool but certainly harder. Thanks for > the links. Even if we don't use the built-in browser for git credentials I > imagine having an understanding will be useful in other login contexts. In the git credentials problem I wouldn't use this built-in browser password support. Firstly, this isn't save (see Gosia's comment on the top of the discussion), secondly, this saves just one click which isn't the best we could get (still you would have to click 'more' and 'ok'). > 4) It may be the easiest approach but... Well, I can think of one extra 'trick' solution. Recently I've read about a problem where a web application needed to remember all opened tabs. When creating a new Orion tab, we could simply save a self-reference in the browser local storage. After we destroy an Orion tab, we could drop the reference in the local storage. This allows us to control when the Orion application is closed, so we could use this in the persistent local storage solution (point 4). If we detect that Orion was closed, we erase all git credentials in the local storage. This way we have a 'session storage' which is available to all tabs and lives only when we use Orion. I haven't investigated this from a technical point of view in detail yet, but it seems to be possible to implement and working even on IE6.
Alright, you seem insistent on going for gold and doing your homework so by all means go ahead and we'll see what comes out of it. To be honest I also prefer a client-side solution so am really interested to see what you do. With that said, I don't particularly feel like rushing a partly baked security solution into Orion and want to take our time to make sure we're getting things right. I'm pretty confident we could definitely do one of the session based solutions for 1.0 but am less certain for something like a more durable credential store. What that means is we might need to make a call in a few weeks and possibly switch gears closer to the 1.0 release but that's fine. Adding Oleg to the CC as he's for a large part responsible for Eclipse's secure storage so can hopefully add to the discussion when the time is right. Please keep this bug live with your thoughts as you go along.
I purposed an experimental fix in bug 387878 using persistent local storage. Please feel free to check it out and comment.
(In reply to comment #15) > Well, I can think of one extra 'trick' solution. Recently I've read about a > problem where a web application needed to remember all opened tabs. When > creating a new Orion tab, we could simply save a self-reference in the > browser local storage. After we destroy an Orion tab, we could drop the > reference in the local storage. This allows us to control when the Orion > application is closed, so we could use this in the persistent local storage > solution (point 4). If we detect that Orion was closed, we erase all git > credentials in the local storage. This way we have a 'session storage' which > is available to all tabs and lives only when we use Orion. > > I haven't investigated this from a technical point of view in detail yet, > but it seems to be possible to implement and working even on IE6. Unfortunately this approach has to be dropped since only simple objects might be stored in local storage and by simple I mean objects which might be stringified using native JSON support. JSON.stringify on a window object will not work at all, furthermore, objects containing functions will loose them after turning into a string.
Maybe we could think of a browser plugin which would handle clearing local storage after a specific user-defined timeout.
We do not plan to encrypt local storage (Bug 387094), so I'm closing Bug 359952. The idea from comment 19 sounds interesting, could you raise a separate bug for that Maciek?
