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?
Related
I utilized the realm encryption example to make a Key and encrypt the Realm database. Then I used the Realm().writeCopyToPath(_:encryptionKey:) to make a copy to ship with my app as indicated by the documentation. I believe its my lack of knowledge in encryptions, but how does a shipped app know the encryptionKey when the user downloads the application for the first time as the key was stored in the keyChain. I assume that hardcoding the encryptionKey is a bad idea so I was wondering what the correct approach to doing this was. Thank you for your time.
It's the lack of general technical feasibility, which makes it hard to come up with a solution. When you ship encrypted prepopulated data, you have to include the encryption key as well, which means in effect that the data is not secure anymore because security by obscurity doesn't really work.
If you have some data to prepopulate, which you wouldn't consider to be sensitive, but want to store sensitive user data in your Realm, then I'd recommend loading the plain bundled data from a separate read-only Realm instance and use writeCopyToPath(_:encryptionKey:) at runtime, with a randomly generated key, you can place in the user's keychain.
While if you're afraid that e.g. your level data for your game will be stolen on a jailbroken device, where you can't count on the FairPlay encryption, bundling an encrypted Realm gives you another level of hardening for a possible "attacker". But you should make sure that you obfuscate the encryption key when you integrate it.
Depending on your use-case, you can use one of both ways or combine them both.
Beside that there is a CocoaPods plugin cocoapods-keys, which is a popular way with some great ideas how to manage encryption keys while development.
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 have no idea how to store username and password details so that the user does not have to login everytime for the iPhone app.
Can anyone lead me in the right direction? I can't seem to find what to do.
Thanks!
You should be using the Keychain API. It will encrypt the data (not hash, as if you have to send it a the server, then the hash wouldn't be any use).
It's a bit of a pain, so take a look at some of sample code and 3rd-party wrappers available on the internet.
You can use Core Data or SQLite or any other storage (XML, JSON), since there are no cookies in iPhone.
Core Data
http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html
SQLite
http://dblog.com.au/iphone-development-tutorials/iphone-sdk-tutorial-reading-data-from-a-sqlite-database/
Also remember to hash the password you should use MD5 at least.
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.
I would like to encrypt a string with AES 256 on the iPhone but have not found much via google. What I am trying to do is post some data to a web site as part of a game I am creating, but I do not want the user to be able to cheat by seeing how it is posted because it is plain text. So I want to post one encrypted string to my php page (ala www.test.com/test.php?encrypted= etc...) and then the php script will decrypt it and do what it needs to if it is valid.
You can just use the CryptoHelper which is adopted by CyrptoExercise Sample Project
A much easier approach here would be to use an HTTPS POST, which would give you similar protections with far less code, though there are still difficulties for solving the problem you're attacking. The kind of solution you're describing generally requires some kind of shared secret, and it's very hard to protect code using a shared secret for long. You may find these posts helpful:
Machine ID for Mac
Store an encryption key in Keychain while application installation process
Obfuscating Cocoa
Still, HTTPS is probably a much better solution than AES here.
Check out this site: http://iphonedevelopment.blogspot.com/2009/02/strong-encryption-for-cocoa-cocoa-touch.html