I have question about credential caching in applications. I've searched around on the net for solutions to this problem, but I haven't found anything (which is really surprising, since this is something that every Facebook, Twitter, and email client application has to deal with).
My question is this:
Let's say I'm building some simple Twitter client. I don't want to force the user to enter their password every time. How do most applications tackle this problem? At some point, the client needs to make an API call to authenticate (which includes the password, which is usually in plain text). However, saving the password in plain text somewhere not the correct solution, obviously. So, how do most apps do this safely? I suppose you could cache the password in a file or db if the password is encrypted, but then how do you safely store the decryption key? Or is it generated at runtime using unique information from the client machine as a seed?
Are there any resources (articles, books, etc.) that talk about this? How do most apps handle this?
Thanks!
Single-sign-on (SSO) setups accomplish what you describe typically by providing centralized methods to generate, distribute and validate a key using some type of session ID.
See for one method (used by StackExchange/StackOverflow):
http://openid.org/
Here's something I didn't know: This category of functionality is known as Federated Identity. For instance, our web system where I work offers (but doesn't require) Shibboleth. See here for a list of options:
http://en.wikipedia.org/wiki/Category:Federated_identity
Related
I need to store login credentials with electron js because it doesnt save them like all browsers. I have seen a lot of questions like this, but I never found a solution. I have seen in the electron docs about the safeStorage feature. is the it safe enough/good enough to store login credentials on the client side? if not what other tools are available to do that? I have heard about keytar but is it good?
The safeStorage api in electron exposes OS-level encryption/decryption using current user's secret key - please refer to electron source and chromium's os_crypt. On windows it utilizes DPAPI while on *nixes it uses whatever password manager the OS has as the documentation suggested.
is the it safe enough/good enough to store login credentials on the client side?
Depends, you should define "secure" first.
Ask yourself, should the same user allowed to read whatever value inside the encrypted text? A tech-literate person might write his own tools to decrypt things you store using that API you are out of luck. See this QA for further discussion.
if not what other tools are available to do that?
There are a lot of tools (and encryption algorithm) to encrypt stuff in nodejs. However, you have to remember an encryption require you to have a key of some sort and the key need to be protected too. Hence, try your best to avoid egg-chicken problem with your key of keys.
OS-based key storage avoids the key of keys problem by storing the "master key" in a way that only accessible using its API. At runtime, you can't retrieve the key at all, you just send a set of bytes for the OS to magically encrypt/decrypt. While at rest, the OS may rely on secure storage such as TPM (Trusted Platform Module).
is electron's safeStorage for passwords and login credentials?
Depends, if you are running a web service it is preferrable to not doing so. You should never dump end user's user name/password directly on a storage that you can't guarantee its safety by yourself (e.g. your server). You should, put an identifier which can be revoked or may expire at later date - token or cookies.
Imagine the trouble when your end user device get stolen. If it's a token/cookie, they can request you to revoke their access from that device - similar to "Log me out from all other device."
However, if its an in-situ application that authenticates to itself then its a fair game - though keep in mind about the first point. Its all down to your security model.
I'm using a local storage value to check whether a user is logged into my Chrome extension.
Can users edit their own local storage values? If I were to use their user ID in my database, I wouldn't want them to be able to log in as something else just by editing that ID, e.g. incrementing by 1.
Should it be something that the user shouldn't be able to see? I also considered using their salt, but I might not want to reveal that to the user.
You are right to be concerned. Generally, client-side code and data can't be trusted because it's in the hands of the attacker. The question is identical to the problem faced with web cookies: a browser can report anything at all as cookie data, so the server can't trust it. You have two general options to get around this problem. One is an HMAC, and the other is public-key signatures. Both require a server, but only the latter can verify without a server.
An HMAC requires that the secret remain inaccessible to the attacker at all times, but it's required for both generation and authentication (that is, that it stay on the server and be verified on the server). You haven't given us enough information to tell whether your extension is appropriate for this use case. Most industrial-strength cookies these days use some variant of an HMAC.
Public-key signatures require that the signing be done in secret (that is, on the server), but after that point the client can verify it without talking to the server.
The big problem that you'll face with any of these schemes is that two people can collude to copy one person's credentials to another machine, or one person can steal another person's credentials. Again, with client-side code you can't really trust anything. But either of these schemes prove that an attacker didn't make up login credentials entirely on his or her own.
Think of this problem as a web cookie problem. However you solve that problem, you can also apply it to chrome.storage.
My goal is a secure login in system such as stackoverflow uses. I am a newbie but as you have probably seen I have spent all day looking up stackoverflow articles on security. As a result of this research I have now worked out a plan of attack. In particular this page was a great help Using OpenID for website Authentication. Can you please tell me if the following system would be a secure system and if not how should I improve the system.
Use OpenID to validate users.
Once a user has been validated by OpenID get user's email address from OpenID.
Hash the email address and store in session variable.
Compare Hashed email address to list of hashed email addresses in databases
Return content appropriate to that user based on the hashed email address.
In particular I am nervous about using the email address instead of the ProviderOpenID.
Please assume that I have (as I have found answers to these questions on other stackoverflow pages):
Properly destroyed sessions after use.
Setup my server to store session data in an inaccessible location.
Setup my database in a secure manner.
I am using SSL to ensure traffic cannot be intercepted.
Thanks in advance.
In general, your way better of using some authentication architecture for the language you are using that supports OpenID. Not only is it more secure, its just easier, you write less code, and you don't have to maintain that code or test it. There are ones for PHP,python,c#/asp.net, rails. A lot of frameworks also have support.
First, why not use the provided ID ?
I think you have two problems:
Its possible that an openID provider could return a email address for a different domain than the provider's.
For example, gmail could authenticate me correctly but I could specify that my email address was billg#microsoft.com. Then you would read my identity as me being Bill Gates despite the fact that it is not. There are of course ways to prevent this, but the standard system probably has safeguards included and even if it doesn't, it is someone else's responsibility to fix them and other people will be looking at those issues.
If I am reading the wikipedia article correctly, openID id's are not necessarily email addresses
This is not a security problem , but it does break expected behavior.
Many users – myself included – would like the security of having everything they do on a web service encrypted. That is, they don't won't any one at the web service to be able to look at their: posts, info, tasks, etc...
This is also major complaint in this discussion of an otherwise cool service: http://news.ycombinator.com/item?id=1549115
Since this data needs to be recoverable, some sort of two-way encryption is required. But unless you're prompting the user for the encryption key on every request, this key will need to be stored on the server, and the point of encrypting the data is basically lost.
What is a way to securely encrypt user data without degrading the user experience (asking for some key on every request)?
-- UPDATE --
From #Borealid's answer, I've focused on two possibilities: challenge-response protocols, where no data (password included) is sent in the "clear", and non-challenge-response protocols, where data (password included) is sent in the "clear" (although over HTTPS).
Challenge-response protocols (specifically SRP: http://srp.stanford.edu/)
It seems that its implementation would need to rely on either a fully AJAX site or using web storage. This is so the browser can persist the challenge-response data during encryption and also the encryption key between different "pages". (I'm assuming after authentication is completed I would send them back the encrypted encryption key, which they would decrypt client-side to obtain the real encryption key.)
The problem is that I'm either:
fully AJAX, which I don't like because I love urls and don't won't a user to live exclusively on a single url, or
I have to store data encryption keys in web storage, which based on http://dev.w3.org/html5/webstorage/ will persist even after the browser is closed and could be a security vulnerability
In addition, as SRP takes more than one request ( http://srp.stanford.edu/design.html ), there needs to be some persistence on the server-side. This is just another difficulty.
Traditionally
If I'm ok transmitting passwords and data in the clear (although over HTTPS), then the client-side issues above are not present.
On registration, I'll generate a random unique encryption key for the user, and encrypt it using their password and a random salt.
In the database, I'll store the user's password hash and salt (through bcrypt), encrypted encryption key, encryption key salt, and encryption iv.
After an authentication, I'll also need to use their password to decrypt the encryption key so that they may view and enter new data. I store this encryption key only temporarily and delete it when they explicitly "log out".
The problems with this approach is that (like #Borealid points out) evil sysadmins can still look at your data when you are logged in.
I'm also not sure how to store the encryption keys when users are logged in. If they are in the same data store, a stolen database would reveal all data of those who were logged in at the time of theft.
Is there a better in-memory data store for storing these encryption keys (and challenge data during an SRP authentication)? Is this something Redis would be good for?
If the data need to be recoverable in the event of user error, you can't use something like a cookie (which could get deleted). And as you point out, server-side keys don't actually secure the user against malicious sysadmins; they only help with things like databases stolen offline.
However, if you're running a normal web service, you've already gotten pretty lucky - the user, in order to be unique and non-ephemeral, must be logged in. This means they go through some authentication step which proves their identity. In order to prove their identity, most web sites use a passed credential (a password).
So long as you don't use a challenge-response authentication protocol, which most web sites don't, you can use an encryption key derived from a combination of a server-side secret and the user's password. Store the encryption key only while the user is authenticated.
If you do this, the users are still vulnerable to sysadmins peeking while they're using the service (or stealing their passwords). You might want to go a step further. To go one up, don't send the password to the server at all. Instead, use a challenge-response protocol for authentication to your website, and encrypt the data with a derivative of the user's password via JavaScript before uploading anything.
This is foolproof security: if you try to steal the user's password, the user can see what you're doing because the code for the theft is right there in the page you sent them. Your web service never touches their data unencrypted. This is also no hindrance to the normal user experience. The user just enters their password to log in, as per normal.
This method is what is used by Lacie's storage cloud service. It's very well done.
Note: when I say "use foo to encrypt", I really mean "use foo to encrypt a secure symmetric key which is then used with a random salt to encrypt". Know your cryptography. I'm only talking about the secret, not the methodology.
None of those other solutions are going to maintain the feature set requested -- which specifically wants to preserve the user experience. If you look at the site referenced in the link, they email you a nightly past journal entry. You're not going to get that with JavaScript trickery per above because you don't have the browser to depend on. So basically this is all leading you down a path to a degraded user experience.
What you would want, or more precisely the best solution you're going to find in this space, is not so much what wuala does per above, but rather something like hush.com. The handling of user data needs to be done on the client side at all times -- this is generally accomplished via full client-side Java (like the Facebook photo uploader, etc), but HTML/JavaScript might get you there these days. JavaScript encryption is pretty poor, so you may be better off ignoring it.
OK, so now you've got client-side Java running a Journal entry encryption service. The next feature was to email past journal entries to users every night. Well, you're not going to get that in an unencrypted email obviously. This is where you're going to need to change the user experience one way or the other. The simplest solution is not to email the entry and instead to provide for instance a journal entry browser in the Java app that reminds them of some old entry once they get to the website based on a link in the daily email. A much more complex solution would be to use JavaScript encryption to decrypt the entry as an attachment inline in the email. This isn't rocket science but there is a fairly huge amount of trickery involved. This is the general path used by several web email encryption services such as IronPort. You can get a demo email by going to http://www.ironport.com/securedemo/.
As much as I'd love to see a properly encrypted version of all this, my final comment would be that journal entries are not state secrets. Given a solid privacy policy and good site security semantics, I'm sure 99% of your users will feel just fine about things. Doing all this right with true security will take an enormous amount of effort per above and at least some design/UE changes.
You should look into the MIT project CryptDB which supports querying an encrypted database using a subset of SQL. (see the forbes article, mefi thread, or Homomorphic encryption on wikipedia)
There is the Tahoe-LAFS project for cloud storage too, which conceivably could be leveraged into a fully anonymous social networking application, one day in the distant future.
If you want to perform computations on a server without even the server being able to see the data, you may be interested in knowing about fully homomorphic encryption. A fully homomorphic encryption scheme lets you perform arbitrary computations on encrypted data, even if you can't decrypt it. However, this is still a topic of research.
For now, I guess your best bet would be to encrypt all posts and assign meaningless (e.g. sequential) IDs to each one. For a more in-depth discussion of how to encrypt server-side data with today's technology, look up.
Here's the situation: we have a common library which can retrieve database connection details from a central configuration store that we have setup. Each application uses this library when working with a database.
Basically, it will call a stored procedure and say "I am {xyz} application, I need to connect o " and it will return the connection details for that applications primary database (server, instance, database, user, and password).
How would one go about locking that down so that only application {xyz} can retrieve the passwords for {xyz} databases (there is a list of database details for each application... i just need to secure the passwords)?
The usual way is to have a different config store per app and give each app a different user/password to connect to the config store.
That doesn't prevent anyone from changing the app and replacing the user/password for app X with the values from app Y but it's a bit more secure, especially when you compile this data in instead of supplying it via a config file.
If you want to be really secure, you must first create a secure connection to the store (so you need a DB drivers that supports this). This connection must be created using a secure key that is unique per application and which can be verified (so no one can just copy them around). You will need to secure the executable with hashes (the app will calculate its own hash somehow and send that to the server who will have a list of valid hashes for each app).
All in all, it's not something trivial which you can just turn on with an obscure option. You will need to learn a lot about security and secure data exchange, first. You'll need a way to safely install your app in an insecure place, verify its integrity, protect the code against debuggers that can be attached at runtime and against it running in the virtual machine, etc.
Off the top of my head, try PKI.
Are you trying to protected yourself from malicous programs, and is this a central database that these applications are connecting to? If so you should probably consider a middle layer between your database and application.
I'm not sure this applies to your case, depending on how what your answers to the abovementioned would be, but by the comments it sounds like you are having a similar case to what this question is about.
Securing your Data Layer in a C# Application
The simplest/most straightforward way would be to store the passwords in encrypted format (storing passwords in plaintext is just plain bad anyhow, as recently demonstrated over at PerlMonks) and make each application responsible for doing its own password encryption/decryption. It would then not matter whether an app retrieved another app's passwords, as it would still be unable to decrypt them.
One possibility is to keep the passwords in the database in an encrypted form, and convey the encryption key to the allowed application(s) in a secure connection.Then, only the application with the encryption key can actually get the passwords and not others.