Forgive me if this is a stupid and obvious question, but I'm having trouble googling for the correct resources. I'm not a security expert and I'm struggling to understand how to properly go about this.
Here's the scenario. I have an internal application on an internal server: not something that will ever go out to a client site. This application has a database of username and password pairs that are used to talk to secure web services. I have no need to keep these passwords secret from colleagues, but I want to protect them in case the server is attacked and the data stolen.
Traditionally one would salt and hash them. This is a process I understand in principle but it depends on the user entering a password which can then be validated against the stored hash. That's not the case for me.
So: searching around there are various solutions that use a fixed "pass phrase" to secure a string. Here's a one example, https://stackoverflow.com/a/10177020/271907 and here is another https://stackoverflow.com/a/10366194/188474.
However, as I understand it neither of these offers a useful solution in my case. That "pass phrase" is going to have to be stored somewhere for my application to do its work. If I hard-code it into the application it can be reverse engineered. If I encrypt it and put it in a separate file it can be stolen and worked out using a rainbow table.
I looked into using reg_iis to encrypt a key as per Encrypting Web Config using ASPNET_REGIIS but, to be honest, that just left me even more confused. I'm not even sure whether or not these encrypted config files can be ported between machines or whether I'd have to re-encrypt between dev and test and live. I don't know how secure they are either: AFAIK there has to be a key somewhere and if there's a key it can be broken.
To further muddy the waters I found this answer which doesn't use a key: https://stackoverflow.com/a/10176980/271907. However the author admits it's out of date and I have no idea how secure the result is.
Is there any kind of sensible approach to solving this problem that doesn't leave a hole in the security somewhere?
Any solution where you decrypt the password to check it is going to fundamentally be insecure because your application must always know how to do that decryption.
You can make it harder by not storing the decryption key in the code, but wherever you put it a hacker that can compromise your code can probably access anything it can access too.
Even if your application security is rock solid; your passwords are still plain text in your DB and if that gets compromised then lots of your users are exposed.
That said - this is an internal-only, low risk system. Your best course of action may be to let your bosses know the relative risk vs the cost of proper security and let them make an explicit business call (and carry any future blame).
The only way of doing this without leaving a hole in the security is by hashing and salting the passwords with a one-way algorithm. The fact that current passwords are plain text shouldn't be a problem - there are lots of ways to push users to encrypt them, but easiest is just to do it for them: next time they log in, if they have a plain text password encrypt it. Then after a suitable wait (depending how often your users log in) remove the old password and check against the new hash.
The golden rule is: if you store passwords you must hash them in a way you can't reverse
The only other option is for you to not authenticate at all - use NTLM or AD or OAuth to get some other service to authenticate the user and just trust that source instead.
If instead you're looking to secure the credentials the application uses itself then you have a similar problem, but the focus shifts. You still can't do much to avoid exposure if the host machine is compromised, but most attacks will only target files.
This can be a problem if all your connection details are held in a web.config or appsettings.json as compromising those files can expose your SQL server or other service passwords.
This is where you can use ASPNET_REGIIS - it lets you add secret configuration that IIS can access, but that isn't held in plain text with the web files.
In .NET core there's new Microsoft.Extensions.SecretManager.Tools that do the same thing.
Both of these add a layer of protection for any application credentials that would otherwise be stored in plain text on disk. Attackers must compromise the machine to get at them, rather than just the files.
In both cases these configuration details are no longer portable - you'll have to set them up again (and re-encrypt) on each server.
However, you only really need the additional protection in live - in development or testing sandboxes you can just use the plain text config, and then override the details with the encrypted settings on the live server.
Our system is built using MVC4-EF6-SimpleMembership.
I'm struggling for 2 days now with how to enable an affiliate company website to login to our system.
What I wanted to implement is a simple GET from their site to ours (we would check the request comes from their domain), where they would pass in an encryption or hash of the password along with a username (not hashed/encrypted).
It turns out I don't have an encrypted/hashed password, which I can give them in order to use it and login, nor I have a way to recover the password in order to hash it myself and most importantly to manage to login with it from code.
Also, I didn't find a way to use the encrypted password field inside the webpages_Membership table. I thought that would be the token to send to our affiliate, but can't see any use for it.
Any ideas?
P.S.
I know there's the OAuth possibility, but I'm afraid to loose time figuring this out and then being dependent on the affiliate site. Is this a wrong approach?
Thanks very much for any help.
This whole approach is a really bad idea, and could very easily open your application up to hackers. You really need to learn more about how to handle authentication with trusted third parties if you're going to go forward, even if it costs you time. What it costs you time now it saves you in the long run in liability.
I'm not clear on your use case for them logging in right now. If it's a human being logging in, just provide them "normal" credentials and have them log in normally (i.e. through a web page POST to get a session cookie, etc).
If you are looking for a way for one of their applications to perform actions on someone's behalf (e.g a cron job or to enable integration with their services), then you should look into providing an API (not using a website per se but a REST or SOAP API). There's a number of mechanisms for that as well (Javascript Web Tokens, SAML assertions, etc).
Finally, if you're intending one of your users on their site to authorize their site to pull information about your user, or perform actions based on your user's wishes, then that's the "sweet spot" for OAuth.
Do not go forward with your plan of issuing out hashes of people's passwords. That isn't how the auth works at all, even if it were a good idea to do so. Standards exist for a reason.
I've used ASP.NET MVC with entity framework (most recent of both) to extend an existing website's data model, but without changing user accounts and user authentication. Feel free to answer this by pointing me to other documentation or learning resources.
My question is: How does ASP.NET handle the passing of user credentials over the wire, the authentication of those credentials, and storing user account credentials? And, how would I do that myself 'manually', in terms of securing their information on front end, in transit, processing, and storage?
Security at the various stages:
Front End - No idea, but make sure forms are validated, I'm guessing? Is this the user's problem?
Transit - Use an encrypted protocol (HTTPS?), but I'm not sure how to set that up in terms of appropriate controller methods, views, and certificates.
Processing - Decrypt username/password to plaintext, hash both and find matching record in the user account table, overwrite or make sure plaintext variables aren't hanging around in code.
Storage - Only store hashes of username/password on the database.
Then once authenticated, create user-session/key that will expire at some point. Again, I'm not sure how to do this 'manually' with ASP.NET, but I know that it happens with the built-in/default login setup.
Front End
Data is not secure. Passwords are entered in an input with type "password", which will obfuscated the entered information (preventing over-the-shoulder style attacks). However, the plain-text value is exposed via JavaScript and can be read by keyloggers or other client-side malware. There's not much you can do about any of this. Ultimately, the end-user is responsible for the security of their machine.
Transit
Always, always, always use HTTPS. It's not foolproof, as was seen by the recent Heartbleed attack, but it's better than just sending everything plain-text over the wire with HTTP. Except for fundamental flaws like Heartbleed, with HTTPS, you need only worry about protecting your certificate's secret key. HTTPS is utilizes two-way encryption with secret and shared keys. The shared key is sent to the client allowing them to encrypt what it sends, but not decrypt, while the secret key allows the encrypted text sent by the client to be decrypted server-side. Hence, the need to protect your secret key.
As far as your controller actions go, if you want to enforce HTTPS only on the action, such that if the user can only access your login page, for example, at https://domain.com/login, rather than http://domain.com/login, you'd add the attribute, [RequireHTTPS]. This attribute can be added at the action level to protect just that action, at the controller level to protect all actions within that controller, or globally to force your entire application to be HTTPS only.
Processing
You do not manually decrypt the username/password. If you're using HTTPS, your application will be handed the already decrypted values by the web server. Dealing with plain-text in your application code is not problematic and is pretty much necessary. I suppose that if some malware running on your server could gain access to the IIS process in memory and decompile the machine code at runtime into to something usable where they could get at the plain-text password, etc., it would be possible to exploit this, but it's a non-trivial hack and would require your server to be severely compromised already.
Storage
Of course you only store hashes in persistent storage. These are created with one-way encryption, where you have a key and generally a randomized IV value. As long as you do not leak both the key and the IV, it is impossible to decrypt the stored value into the original string. The only vector for attack is collisions, where you essentially encrypt millions of different strings in different ways and check for a match against the target encrypted value. However, most modern encryption algorithms make this sort of attack nearly impossible, requiring even a supercomputing platform hundreds or even thousands of years to ever create a viable collision. Just stay way from MD5, which does regularly emit collisions and has entire blackhat databases devoted to matching up encrypted values to plain-text values.
I am using asp.net mvc 2.0 and I am wondering how secure is it to put information in a cookie?
Like I put in my cookie a forms authentication ticket that is encrypted so can I put information that could be sensitive in there?
string encryptedTicket = FormsAuthentication.Encrypt(authTicket)
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Like I am not storing the password or anything like that but I want to store the UserId because currently every time the user makes a request to my site I have to do a query and get that users Userid, since every table in my db requires you to use the userId to get the right row back.
So these start to add up fast so I rather have it that if a user is authenticated once then that's it till they need to be re-authenticated again. If I would store this userId I could save so many requests to the database.
Yet I don't want it floating around in clear text as potential someone could use it to try to get a row out of a database when they really should not be.
Show how good is this encryption that Authentication uses?
The encryption is good enough, that's not the weak link.
The weak link is that the cookie value could be intercepted, and someone else could impersonate the user.
So, the information in the cookie is safe enough, but you can't protect the cookie itself.
The title of your question doesn't really match what you are asking. There are two different things you are asking here.
1. Is there a secure way to store data in a cookie?
The answer is yes. To safely store data in a cookie you have to encrypt the data you want to store then sign the encrypted data. Encrypting it prevents attackers from being able to read the data, signing it prevents attackers from modifying the data. This will ensure the integrity of the data. You could use this method to store data about the user you want to keep private (their email address, date of birth, etc). Note: Securely storing data in a cookie is not a safe way to authenticate a user! If you stored the user id of the user in the signed and encrypted cookie, nothing prevents an attacker from stealing the entire cookie and sending it back to the server. There's no way of knowing if the authentication cookie came from the same browser where the user entered their user name and password. Which leads us to the second question (the one you were actually asking)...
2. Is there a secure way to authenticate a user with a cookie?
Yes. To securely authenticate a user you must combine the techniques from question 1 with SSL (https). SSL ensures that only the browser will be able to access the authentication cookie (the signed encrypted cookie with the user id in it). This means that your login process (accepting the users name and password, as well as setting the authentication cookie) must happen over SSL. You must also set the HttpCookie.Secure property to true when you set the authentication cookie on the server. This tells the browser to only include this cookie when making requests to your website over SSL. You should also include an expiration time in the encrypted auth cookie to protect against someone forgetting to log out of your site while they are at the library. A side affect of this approach is that only pages on your site that are SSL will be able to authenticate the user. Which brings up a third question...
3. How do you securely authenticate a user without using SSL?
You don't. But you do have options. One strategy is to create two auth cookies at login, one regular cookie and one that is ssl-only (both encrypted and signed though). When performing sensitive operations on the users behalf, require the page be in SSL and use the SSL-only cookie. When doing non-sensitive operations (like browsing a store that is customized based on the country their account is in) you can use the regular auth cookie. Another option is to split the page so that information that requires knowing who the user is is retrieved async via AJAX or json. For example: You return the entire page of the blog over http and then you make an SSL AJAX request to get the current users name, email, profile pic, etc. We use both of these techniques on the website I work on.
I know this question was asked almost a year ago. I'm writing this for posterities sake. :-)
Along with cookie encryption, you should also implement a rotating token to prevent replay attacks.
The idea being that the encrypted cookie contains some value which can be compared to a known value on the server. If the data matches, then the request succeeds. If the data doesn't match then you are experiencing a replay attack and need to kill the session.
UPDATE
One of the comments asked if I meant to store the value in the cookie. The answer is yes. The ENTIRE cookie should be encrypted, which can be automatically done through the use of an HttpModule. Inside the encrypted cookie is any of your normal information + the changing token.
On each post back, check the token. If it's valid, allow the transaction, create a new random token, store in the cookie, and send that back to the browser. Again, in an encrypted form.
The result is that your cookie is secure (you are using 3DES?) and any attacker would have an extremely limited window of opportunity to even attempt a replay attack. If a token didn't pass muster, you could simply sound the alarm and take appropriate measures.
All that's needed server side is to keep track of the user and their current token. Which is usually a much smaller db hit than having to look up little things like the users name on each page load.
UPDATE 2
I've been trying to figure out whether this is better or worse than keeping the changing value stored in session. The conclusion I've come to is that storing a rotating value in session on the web server does absolutely nothing to prevent replay attacks and is therefore less secure than putting that value in a cookie.
Consider this scenario. Browser makes request. Server looks at the session id and pulls up the session objects, work is then performed, and the response is sent back to the browser. In the meantime, BlackHat Bob recorded the transaction.
Bob then sends the exact same request (including session id) to the server. At this point there is absolutely no way for the server to know that this is a request from an attacker. You can't use IP as those might change due to proxy use, you can't use browser fingerprinting as all of that information would have been recorded in the initial exchange. Also, given that sessions are usually good for at least 30 minutes and sometimes much longer, the attacker has a pretty good sized window to work in.
So, no matter what, to prevent replay you have to send a changing token to the browser after each request.
Now this leaves us with the question about whether to also store values such as the user id in an encrypted cookie or store it server side in a session variable. With session you have concerns such as higher memory and cpu utilization as well as potential issues with load balancing etc. With cookies you have some amount of data that is less than 4kb, and, properly done, in the 1kb or less range that gets added to each request. I guess it will boil down to whether you would rather add more / larger servers and internal networking equipment to handle the requests (session) or pay for a slightly larger internet pipe (cookie).
As you've stated, a good practice for storing any data in cookies is to encrypt the data. Encrypt before putting into the cookie, and decrypt after reading it.
In the example of storing a user identifier, choose something that's not likely to be used against your system. For the user id, use a guid rather than the likely incrementing integer that's the PK on the database table. The guid won't be easily changed to successfully guess another user during an attack on your system.
Once the user has been identified or authenticated, go ahead and store the user object, or key properties in Session.
In an ideal world with an ideal cipher this wouldn't be a problem. Unfortunately in the real world nothing is ideal, and there never will be an ideal cipher. Security is about solving these real world threats. Cryptographic systems are always vulnerable to attack, weather it be a trivial(brute force) attack or by a flaw in the primitive its self. Further more it is most likely that you will botch the implementation of the primitive, common mistakes include non-random or null IV, Key management, and incorrect block Cipher mode.
In short this is a gross misuse of cryptography. This problem is best sovled by avoiding it all together by using a session variable. This is why sessions exist, The whole point is to link a browser to state data stored on the server.
edit: Encrypting cookies has led to the ASP.NET oracle padding attack. This should have been avoided all together by using a Cryptographic Nonce. Like i said, this is a gross misuse of cryptography.
For your very specific scenario (user id), the short answer is NO!
For the long answer, imagine this hypothetical scenario:
You navigate to stackoverflow.com;
Fill your username/password and submit the form;
The server sends you a cookie containing your user ID, which is going to be used to identify you on the next requests;
Since your connection was NOT secure (HTTPS), a bad guy sniffed it, and captured the cookie.
The bad guy gains access to your account because the server didn't store, let's say, your IP address, and thus, can't distinguish between your machine and the bad guy's.
Still in this scenario, imagine the server stored your IP address, but you're on a corporate LAN, and your external IP is the same of another 100 machines. Imagine that someone that has access to one of these machines copied your cookie. You already got it, right? :-)
My advice is: put sensitive information on a HTTP session.
UPDATE: having a session implies a cookie (or at least an ugly URL), thus leading us back to the very same problem: it can be captured. The only way to avoid that is adding end-to-end encryption: HTTP+SSL = HTTPS.
And if someone says "oh, but cookies/sessions should be enough to discourage most people", check out Firesheep.
It's okay (not great, but not wrong) from a security standpoint. From a performance standpoint, however, it's something you want to avoid.
All cookies are transmitted from client to server on every request. Most users may have fast broadband connections these days, but those connections are asymetric — the upstream bandwidth used for transmitting cookie data is often still very limited. If you put too much information in your cookies, it can make your site appear sluggish, even if your web server is performing with capacity to spare. It can also push your bandwidth bill up. These are points that won't show up in your testing, which most likely happens all on your corporate network where upstream bandwidth from client to server is plentiful.
A better (general) approach is to just keep a separate token in the cookie that you use as a key to a database lookup for the information. Database calls are also relatively slow (compared to having the information already in memory or in the request), but primary key lookups like this aren't bad and it's still better then sending the data potentially a quarter of the way around the world on every request. This is better for security as well, because it keeps the data off the user's machine and off the wire as much as possible. This token should not be something like the userid from your question, but rather something more short-lived — a key used to index and hide away larger blocks of data, of which your userid is perhaps one part.
For your userID, which is likely only a single integer, as well as other small and important data, keep it in memory on the web server. Put it in the session.
The use you are looking at is the exact intended purpose of being able to store information in the Forms Auth Ticket.
No. It have been shown with Padding oracle attack that receiving encrypt data (CBC) can be dangerous because of the errors leakage.
I'm definitely not a crypto expert but I recently saw a demo where encrypted view-state was decrypt using this attack.
Encrypting the userid value in the cookie only prevents the user from knowing what the value is. It does not
prevent cookie replay (use SSL to
prevent an attacker from intercepting
a victim's cookie)
prevent tampering
(an attacker can still blindly flip
bits in the encoded cookie with a
chance that it will decode to a valid
userid, use an HMAC to prevent this)
completely prevent a user from getting the decrypted value (the user can brute force the value off line, use a strong encryption key to make success less probable)
Encrypting the cookie also introduces a key management problem. For example, when you rotate the encryption key you have to make sure "live" sessions with the old key won't immediately fail. You thought about managing the encryption key, right? What happens when admins leave? It's compromised? etc.
Does your architecture (load balancers, server distribution, ...) preclude using server-side session objects to track this information? If not, tie the userid to the session object and leave the "sensitive" data on the server -- the user only needs to have a session cookie.
A session object would probably be a lot easier and more secure for your stated concern.
To ensure proper auth cookie protection, you should make sure that you specify a secure encryption/hashing scheme (usually in the web.config) by setting the machineKey validation="SHA1" property (I use SHA1 but you can replace that with a different provider if desired). Then, make sure that your forms auth has the protection="All" attribute set so that the cookie is both hashed AND encrypted. Non-repudiation and data security, all in one :)
ASP.NET will handle encrypting/decrypting [EDIT: only the auth cookie!] the cookie for you, although for custom cookies you can use the FormsAuthentication.Encrypt(...) method, so just make sure that you're not sending the UserId via other cleartext means like the querystring.
HttpCookie c;
c.Secure = true;
Obviously this only works when transmitting via SSL, but this setting tells the browser not to send the cookie unless the connection is SSL, thus preventing interception via man-in-the-middle attacks. If you are not using a secure connection, the data in the cookie is totally visible to anyone passively sniffing the connection. This is, incidentally, not as unlikely as you'd think, considering the popularity of public wifi.
The first thing to address is whether the connections involved are secure. If they are not, assume the cookie or anything else between you and the client will be intercepted.
A cookie can be a liability once it is on the client machine. Review cookie theft, cross-site request forgery, confused deputy problem.
Cookies limitations: size, may be disabled and security risk(tampering). Of course if you encrypt cookie, there could be a performance hit. Session and Viewstate would be good alternative.
If you want it to be stored at client side, viewstate would be better. You can encrypt the string userid and store in viewstate. Session would be best option.
If your database calls are slow, consider caching
Viewstate
I've been reading a little about encryption recently and am interested in protecting a licence file from tampering. Now this may not be the best way to do it, in which case I'm open to suggestions. But one way I was thinking of protecting it is to simply encrypt it.
However if I were to use encryption I'd need to use symmetric key, but this raises the question. If I store a key in the source code, with such tools as reflector, is it really worth it? It seems a fairly trivial task to obtain the initalization vector, salt, key etc and therefore break the encryption. Is there a way to protect a key in source? Or is this the completely wrong approach?
If you want to prevent tampering, you want signing/hashing, not encryption. Similar theory - but it means you can validate the file with the public key in the app, without requiring the private key that you keep on your server (and use to issue licenses).
Search for cryptographic hashing / signing.
Anything on the client side of the system can be compromised.
If you encrypt your file you must also somehow place the decryption key in your program. Anyone with a hex editor will be able to step through your code to find this key and then decrypt your license file and also create keys for your system.
Internet activation would be a good way to go, but I would see if you can find third parties to do this for you as they will have been down these roads before.
That said running your license file through some AES 256 encryption can't hurt :).
if you are speaking about MS/.NET environment, i recommend you the DPAPI.
It is an API used to store your data protected by a password. Then you can ask me "but then i have the same problem", the answer is no, because in this scenario you use a user password to protect your data. So what you have to do, to access your data, is run your application under a certain credentials. In MS environment, its the the best solution.
from the documentation:
DPAPI is focused on providing data protection for users. Since it requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. In a typical system, in which the user logs on with a password, the logon credential is simply a hash of the user's password. In a system in which the user logs on with a smart card, however, the credential would be different. To keep matters simple, we'll use the terms user password, logon password, or just password to refer to this credential.
What you're attempting is DRM; there is no 100% way to do this on current PC hardware. There are many measures you can take to obfuscate parts of your program. It's a tradeoff between how much you want to obfuscate and how many hurdles you want to make your paying customers go through.