I have a website where users can create an account, the password is hashed with SHA256 and all the info stored in a database.
I have a game made with unity3d, where the player have to login.
I used the WWW class to reach and get information from a login page of my website (of course no direct acces to the database). But I have to pass the username and password as POST values...
Now I have two question :
I've read that I should use the php password library instead of SHA256, is that really critical?
How can I login in the game without compromising security?
Check out this link here:
If you're a web developer, you've probably had to make a user account
system. The most important aspect of a user account system is how user
passwords are protected. User account databases are hacked frequently,
so you absolutely must do something to protect your users' passwords
if your website is ever breached. The best way to protect passwords is
to employ salted password hashing. This page will explain why it's
done the way it is.
It will give you the basics of how to securely send, store, and use a password in php and even provides tested source code for you to use. Please do not try and come up with your own homebrew solution, use what this resource and make sure you understand it if you want to make your login secure.
Related
I have an app where users are not self-registered, i.e. another user adds them to the system, and they are emailed with their login details. What's the best way to handle this in terms of creating the user and handling the password?
It's the sort of thing where a user is invited in to the system by someone else, answers a questionnaire, then doesn't need to log in again until some point in the future where they might be invited again by someone different, so ideally they will need to be reminded of their login details in the email rather than having to reset their password every time. Obviously in an ideal world people would just remember their passwords but the situation it's used in and the infrequency of access means that people simply don't remember, and the process needs to be as hassle-free as possible to ensure user participation.
The old version of the site used Webforms and ASP.Net Membership with encrypted passwords, which could be retrieved and sent to the user each time they are invited. What is the best practise for Identity, where the user does not supply their own password? Are there other options for logging in users such as:
A unique-link provided in the email which authenticates the user?
A separately encrypted 'passcode' field stored in the AspNetUsers
table which can be decrypted and sent each email?
It's worth pointing out that users with admin-level access to the site would still have the usual secure Identity user/pass setup, my problem is just with the lower level users.
I would forget completely about passwords in this case. ASP.NET Identity provides you with one-time codes that you can use for this.
This tutorial shows you in the section "Set up email confirmation" how to send one-time codes through mail (these are generated by ASP.NET Identity itself):
string html = "Please confirm your account by clicking this link: link<br/>";
You can easily modify that as well as the behavior when the user clicks that link to match what you want to do here.
I am creating a project not very large scale and came to create a system of registration and login. In which cases/projects you might want to use ASP.NET Identity and when you just want to create your own login system, whose creation is much easier?
As a result of Your practice?
Maybe I have to use Form Authenticator?
Do you want social login (google / facebook / twitter / linkedin / etc)?
Do you want two-factor authentication?
Do you require users to confirm an email address as part of registration?
YOU DO WANT TO 1-WAY ENCRYPT THE PASSWORD ...but how?
ASP.NET Identity2 makes doing a lot of these things easier, because they already wrote the code for a lot of this stuff -- password hashing, creating confirmation tokens (for registration / password reset / linking emails to an account), social logins, etc.
Also, #Tim Schmelter makes a very good point in his comment. Security is not easy to get right. When you roll your own registration and login, you are not only making more work for yourself, but you are probably going to leave holes in the registration and login system.
ASP.NET Identity is not an "all or nothing" tool. You can use pieces of it as needed. There is no reason why you can't borrow the password hashing and token generation/validation portions of it, and then use the (non-claims-based) FormsAuthentication to write the cookie. However if you want claims-based authentication and social logins, I would recommend staying away from FormsAuthentication.
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 have been making basic forms applications in C# for a year or two now and have done some very basic log in forms (plain text passwords etc).
I am looking for a better, more secure option for security. I have looked and found some articles about .net membership and I have come across it before in other applications I have used. I feel that searching google sends me around in loops of why X is better than Y and also the resources are diluted by various reccomendations from 3-5 years + ago.
I am very comfortable with SQL and use Visual Studio Express for my development.
All I am looking for is a good resource / link to the most common authentication methods around. This site will eventually end up live on the internet so needs to be secure.
Thank you.
I use the ASP.NET Login Controls. There are other solutions, but this is one area (much like encryption) where I think you're better off not coding up your own solution - there are too many ways to fail.
See also What should every programmer know about security?
First of all the only way You can secure send password is SSL. The only excepion for this is for internet sites which are using windows integrated authentication. Buti in this case You do not send password (so it is still ok).
Second part is storing passwords. If you store them plain, somebody can hack your server and get them. That is way you should store hash of the password.
For me the best way is 2 way authentiation. I use SMS service and password.
Passwords are stored in database where every character is hashed(SHA512 or md5) with SALT. Salt is neccesary because if someone gets into your database he can find passwords and check them in dictionaries. I force user to randomly enter some characters of password + valid code from sms.
Also good way is to use CAPTCHA when user fails to enter data several times.
You should log such invalid login tries and if you think there can be attack on this account, you should block it and inform user about it.
I'm writing a C# application that will be open source and I need to be able to store saved login information for each user. Normally I would just encrypt the password and then store it in a user settings file, but I worry that because of the code being open source it kind of defeats the point of encrypting it. Since all anyone would have to do is look at the code and grab the encryption key.
Granted, it would at least make it a lot harder than the password being stored in plain text. But is there any decent way of encrypting the password, but making it still at least extremely difficult to decrypt it even if you had the source? Maybe make it so it would at least be nearly
impossible to decrypt on any computer other than the one it was encrypted on?
EDIT: Clarification... I'm storing CLIENT side passwords, NOT passwords to validate their login for the service. It's a client to a pre-existing web service of which I have no control. I just want to store the passwords locally for automatic login... like any chat client would.
EDIT 2: Totally sorry for not being clear before. But passwords have to be retrieved in clear text at some point and hashing is NOT an option :( Even if the service would let me pass the password hash that would kinda defeat the purpose because the hash would be as good as a password :P
What you are asking is basically, impossible.
There is no way to safely store a password on a client machine if it needs to be decrypted. This is further aggravated by the fact that you need it to connect to a service, which I presume does not support SSL. In this case, one could trivially find the password by using a network analyzer.
There is a game (closed source, of course) I play that requires a login, the password is saved somewhere but it's encrypted with a key that's unique to each install. I forgot the password once, so I just used Wireshark, and voila - I could see the plain password.
This also reminds me of people complaining about it being easy to reveal passwords in Google Chrome... They obviously don't know better. You can try all the clever tricks you want, but any application security is thrown out the window once someone has access to the machine.
So with this in mind, I would keep the encryption and decryption really simple. At best, you can create a key derived from something unique to the machine, so someone who steals the encrypted password will be unable to decrypt it without access to said unique key.
If you are using this application in Windows you can use DPAPI for storing sensitive data on behalf of the user:
How To: Use DPAPI to Encrypt and Decrypt Data (C#/VB.NET)
Also storing the hash only instead of the full password is a good idea!
I think if you use Rijndal for instance and create random salt values and derive the keys from machine specific things (like some hardware IDs) it will be hard to decrypt, even if you know how it works because you are missing the information of the hardware.
But you might consider storing hashes of the passwords only and iterate at least 1000 times. Hashes cannot be covnerted back to the original password.
Yet another idea: would it maybe be an option to just leave the implementation up to who ever is going use your source and make the encryption abstract? Doesn't work of course if you offer a built bundle to download. But then again: in the build you could use your own "secret" encryption and stull have it abstract in the source.
Maybe you can encrypt password using some machine specific values, like mac or sth.. If someone get source and encrypted password but no full access to the machine password should be safe.
Yuo could use babushka doll encryption. You encryt the password with another password, then encrypt that with another password, and do that lots of times eventually writing the last password in clear text. Anyone who wants to get access to the orignal password will get sick of all the unencrypting and give up before they get to the original password.