I'm currently building a couple of ASP.NET MVC 2 sites, and am wondering what my options are for salting a password. With my PHP work, I usually just obtained the timestamp of when a user registered, then appended it to the end of their password string before using SHA1 to hash the entire thing. My instinct is that this approach may not be sufficient.
I'm pretty new to user administration with ASP.NET anyway, so I figure it would be in my best interest to get started with best practices from the beginning. I know that ASP.NET web forms have built-in user administration available, but am unsure about MVC.
The only point of a SALT is to prevent rainbow attacks, where multiple users have the same hash for their password, so reversing one password successfully means you also know it's the password for everybody else with the same hash. Even a single-digit salt will prevent that, since two users with the same password will have different hashes if they have different salts.
As long as the salt is something that won't change, and that is different for every user, any value will work well. Timestamp of their registration, provided you don't update that field (which would invalidate their password hash and prevent their login) is a fine choice.
Related
Passwords are hashed with a salt and are thus "secure" (relatively speaking) by default using has_secure_password in Rails 4. But what I want to do is encrypt the email at rest in the DB so if the database is compromised somehow the emails aren't just in plaintext.
I've looked at just writing my own encrypt/decrypt functions, but that's dangerous. I've looked at attr_encrypted (and have used it before) but it's not really compatible with the new Model.find_by(key: value) syntax that Rails 4+ pushes, and I don't want to create a hacked fix.
Is there anything out there already that will allow me to easily encrypt an attribute in the DB at rest and then decrypt it when I need to find it? I can't use hashes because I need the decrypted value to display and send emails to later.
I've googled for a while but can't seem to find anything like this. Surely encrypt/decrypt is something very basic that's been put into a convenient gem that's been reviewed by the community?
Have you considered the attr_encrypted gem?
I am planning on using the lift's mapper's megaprotouser and I am wondering if I need to hash the passwords before they are inserted into the database, or does it already take care of that?
The MegaProtoUser will not obscure the password by itself, but it uses MappedPassword, which provides that functionality. Check https://github.com/lift/framework/blob/master/persistence/mapper/src/main/scala/net/liftweb/mapper/MappedPassword.scala to see how this is achieved.
If I have a password variable that is used for remote SSL authentication, is it secure to store in the source code?
e.g.
NSString * password = #"password";
Are there better way?
Update: Sorry for confusion, I am not storing the user password, instead, I am storing a password that is used to call our own backend, all the app will use the same password.
My new answer:
Try not to use static passwords to access the back-end, period. What happens if somebody you don't want determines what that password is. Why not use usernames & passwords?
You can also consider using a public key or embedded certificate to allow only your app access to the back end servers.
My original answer:
Sounds like you want to get to know the Keychain.
Here's a tutorial that talks about it:
http://maniacdev.com/2011/07/tutorial-how-to-use-the-ios-keychain-to-store-names-and-passwords/
And here is a related question that talks about the security of Keychain under iOS.
You shouldn't have programs a store static password for all users, but instead have each user set up his/her account & password for authentication and then store that stuff in the keychain.
Any text contained within your application is easily extractable. There's no real way around this - using the strings tool, anyone can see any and all text content statically embedded into your app. However, there are some ways around this - notably, if you split up your string into several static strings and concatenate in the right order, it will be much more difficult to reverse engineer the password contained in your app.
I recommend you take a look at a similar question (How Safe is Information Contained within iPhone App Compiled Code), and specifically, my answer to that question, for a more in-depth explanation of what I mean. (Nimrod's comment on that question is also interesting.)
NO!
build your app. Go to the terminal and type strings and then drag your executable to terminal and press return... You'll see your secret password in plain text :)
You should store its hash.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.
I have a web server that creates a QR code which is [username] + a md5 hash of [username][password].
Where [username] is the user logged in at the time.
Where [password] is a system password set by me and common to web server and the apps.
My Android/iPhone/BlackBerry/Windows app will scan this QR code and use the [username] provided in the QR code to hash with [password] which will tell me that the QR code came from my server.
Obviously if someone were to get hold of [password] then they could create QR codes that did not come from my web server. So is there anyway to safely store [password] in my app or could someone decompile the .apk and find it in classes.dex?
You can obfuscate the password somehow, but ultimately this is only security through obscurity. Someone who wanted to could certainly reverse engineer it.
You probably want to look at public key cryptography to avoid this - even if someone gets access to the public key, they still won't be able to use it to impersonate your server.
No.
If someone is sufficiently motivated, they will be able to reverse engineer a hard-coded password.
Im not sure about the other platforms, but if you put your password hardcoded in plaintext on android they would get it really easily. Other platforms might require more advanced methods. You can hash the password with some more advanced hashing algorithm so that they don't get the original password, but from what you said you don't want them making "fake" QR codes.
The short answer is no, because everything can be cracked somehow if it is on client side.