Saving Account Information in a Common Location

pe2smugmug

So I was wondering if there is a convention for where to save account information (if the user desires), that can be shared across different applications? It seems that this would be convienent for people who use a number of different applications and want to keep their credentials saved. A search of the forums didn't really turn up anything.

On windows, it would seems that somewhere in the registry (HKCU) would be appropriate, probably under HKCU\Software\SmugMug\??

I'm not as familiar with Macs, but in the home directory, there is probably an appropriate location for a similar dot file.

Other questions that come to mind include:
Allowing multiple accounts to be saved?
How to save the credientials? To clarify, saving the password obviously makes no sense; especially when we are given a nice mechanism for password hashes. However, is there a concern about saving password hashes? Windows offers some protection though the DPAPI, and OS X has its keychain, which might be a nice extra layer of protection, or is this overboard?

Thoughts?

-Evan

pe2smugmug

bump
Anyone?

Any official comment at least on how "safe" it is to store the PasswordHash for an account in the HKCurrentUser registry hive?

mjohnsonperl

Storing the password hash, if compromized gives anyone access to any of the content on a user's account via the API system. So although not quite as broad as the actual password itself, it still compromises the content which in this cases is what SmugMug is primarily used to protect.

If you are concerned about the security of storing the password hash, the additional security layers you have brought up would make for good candidates to compliment storing SmugMug account credentials.

There currently is no standard means of storing account information for SmugMug on a system. If there was one, the additional security layers would likely be a requirement.

Matt

pe2smugmug

So a proposed "standard":

The Base Key to store it all in:
HKCU\Software\SmugMug\

Then, a subkey for each account that is saved, based on an index numer starting at 0,
ie,
HKCU\Software\SmugMug\0\
HKCU\Software\SmugMug\1\
HKCU\Software\SmugMug\2\
etc...
If there is only one account saved, it has the 0 slot.

Within each Key, the following name/value pairs:
"E-Mail" - String - required - this one should be self explanatory
"UserID" - DWORD - required - The user ID, again pretty clear
"SaveHash" - DWORD - required - Treat as a boolean (0 or 1), true if the password hash is saved, or false if we are simply saving the last user that logged in.
"PasswordHash" String - optional - If SaveHash==1, then this is clearly required, but otherwise it can be empty or not set. This stores an encrypted version of the PasswordHash (perhaps we should rename the key?), more details on this below
"AutoLogin" - DWORD - optional - Similar to SaveHash, treat as a binary. For this to be true, then SaveHash must be true. When this is set, then the application is allowed (but not required to) auto login the given user account, without prompting. Note: This option should only be true for the first account (in slot 0), to prevent ambiguity as to what account to use.

Regarding storage of the PasswordHash, right now all coding has been done in .NET, but a search did turn up a DPAPI library for Java as well, though this is clearly not cross platorm compatable.

I am going under the assumption that the passwordHash returned from SmugMug is a SHA hash or something similar and that it returns only plain ASCII values, and can be safely cast from a string to a char* or some kind of char[] representation of 1byte per character.
Take that array, and pass it into the DPAPI ProtectData function, with the entropy bytes set to null, and the DataProtectionScope set to the current user. Those returned bytes (now encrypted), are then converted to base64, and then the string or char* representation of that is stored in the PasswordHash registry key.

So in short:
1) Take hash and cast as char* (or byte* really)
2) Encrypt byte*
3) Convert encrypted byte* to base64, and save

Comments? Thoughts?

mjohnsonperl

The thing that might be challenging is getting all the various developers that are doing development to use the centralized account information storage. Typically all the developers are going to have their own ideas for how they want to do something.

I know for me, I'm writing in Perl, and would rather stay clear of the registry because I'd have to come up with an alternative solution for my builds on OS X, so I'll likely use a solution that works cleanly on both like saving a settings XML file, and storing whatever I need in there.

Getting developers to work together, and primarily agree how things should be done, is I would imagine the hardest part here.

pe2smugmug

mjohnsonperl wrote:

The thing that might be challenging is getting all the various developers that are doing development to use the centralized account information storage. Typically all the developers are going to have their own ideas for how they want to do something.

I know for me, I'm writing in Perl, and would rather stay clear of the registry because I'd have to come up with an alternative solution for my builds on OS X, so I'll likely use a solution that works cleanly on both like saving a settings XML file, and storing whatever I need in there.

Getting developers to work together, and primarily agree how things should be done, is I would imagine the hardest part here.

Understood. I am kind of hoping that this sort of thing will get included into libraries, so it all goes on in the background. I am working on including it in my .NET library (which while it will run under Mono, is really targeted to Windows platforms). If Riyad included it in his Java API, then he would probably want to have it check the platform and act accordingly..

If no one else uses it, thats fine. But its always nice when things play well together.