I am looking for a mechanism for users table password field decryption or un-hash for Drupal 7. decryption is required for one of my project. this users table data need to be migrated in another system. any help will be appreciated. thanks in advance.
As of Drupal 7, there is no way to decrypt user passwords ... full stop.
For more details, refer to the answers to this question on Drupal.SE.
Concur with Pierre. Drupal 7 hashes are true hashes and therefore not 'reversible'. The original plaintexts must be known in order to verify them.
Your only other options are either:
cracking them, or
intercepting them at a low level as users successfully authenticate.
But both of these can be challenging (and even distasteful) in multiple ways, that are probably outside the scope of this question (as currently written):
technically (How will you crack them, or how will you intercept?)
security-wise (How can you keep the plaintexts safe? How will you destroy the plaintexts afterwards?)
ethically (How can you do this without disclosing user passwords to yourself?)
Related
I am currently designing a distributed iOs game. It must contains kind of an authentication (username, password pair I think but please give me other idea if you have). I plan to do it through a simple RESTful API coded in Perl.
I know it is kind of a classic problems. I've seen lots of posts on the web talking about how to do this securely. However, too much informations kill its informative goal. So, I am a bit lost. Nevertheless, I've tried to outpoint the basics concepts, namely:
use SSL (so use https url), it allows you not to think about encryption
use embedded private keys shared between the server and the client, but how to embed them is the question! It allows to use HMAC and to do kind of an authentication.
forget about absolute security (because you use security by obscurity): if anyone can destroy your security by decompiling your app, you gonna have problems !
Here are the questions:
how to share private keys ?
what to send to the server ? username/password encrypted ? some api key ?
do I have the right approach (securing a personal restful api) ?
Thanks !
First of all, it's quite broad question. So it may get closed because of this.
Trying to break down your questions to sub-questions/sub-notes
1) First and most important, as you pointed out. There is no absolute security. You should defined what is valuable (what are you trying to protect) and against who are you trying to protect:
unauthorized user
unauthorized user with inner knowledge of your app (reverse engineered)
authorized user with inner knowledge of your app (reverse engineered)
1) https is "the must". As you figured it out, you don't have to worry about privacy and integrity.
2) In most cases, an app should send username and plain password. This password should be hashed by the server (don't forget to add some salt to it) and compare to stored hashes in your DB.
3) I don't think that you need to share any private keys between client and servers for several reasons:
SSL ensures privacy (so no one can eavesdrop)
Encryption of any parameters using shared secret key which is hardcoded doesn't help too much (it could be reverse engineered and extracted from your app)
I would like to add simple password protection in an iPhone App that I am working on. I will probably use crypt() to store the password in my database which in in CoreData / sqlite format.
I think I have a pretty good understanding of how to create and store the password, but in case the user forgets their password, I would like to add a password recovery ability
This is the part that I'm struggling with in iOS. I want everything to be local, so I can't think of a way to use a link to reset a password.
I had thought about emailing the password, but in iOS there is no way to send emails without the person holding the device seeing the contents of the email.
The only way that I can think of is to have one or two "backup passwords" which is basically the answer to a question of the user's choice (or maybe even just storing a reminder question along with the password).
Neither of these are really that secure, although the data being protected in my app is not that critical, so I'm not looking for the most robust solution (just a decent solution that is not too hard to implement, not too inconvenient for the user, and not too hard for a hacker to break).
Suggestions are greatly appreciated.
Thanks,
Ron
Instead of recovering a password, you can prompt to reset a password using criteria that is set up when they initially create their account -- such as mothers maiden name, last-4, etc. This way, you don't need to worry about decrypting a password or sending it to the user. Once they answer enough security questions correctly, they are prompted to reset their password. You can store this data encrypted locally. You'll never need to send a password to the user.
The easiest way is probably to make "password protection" optional and display a warning ("if you forget your password, your data may be irrecoverable!").
It's not going to be that secure: The data is probably going to appear unencrypted in a phone backup, unless you encrypt it yourself. The upshot is that determined users can ask you for help, and you can write them a tool that digs through the unencrypted backup and resets the password.
Avoid the built-in crypt(), which is probably DES-based and limited to 8 ASCII characters. Storing the plaintext password in the keychain is not too terrible an option.
I have some data I’ve spent months collecting, cleaning and structuring. The app I'm building will be able to search the data. So far I'm storing the sqlite file in the users filesystem and not on a remote server because I want the search result to be instant to give users the best experience possible, independently of their connection speed.
But I've just discovered anybody with a jailbroken phone can just "steal" the information store in my sqlite file.
The last thing I want is for someone to get the result of my hard work and publish it on a website which could potentially makes the app useless.
Is there any way to stop this from happening?
Thanks for your help!
What you want is a form of DRM. Ultimately, DRM cannot prevent a dedicated attacker from getting at the underlying data. Anything the user can access can, in theory, be accessed by a malicious application.
You can encrypt the rows of the database and hide the key somewhere in the app, but an intrepid hacker will find it. You can download the whole file on first run and encrypt it with a key unique to that device, but then you have to store the key somewhere or have an algorithm for regenerating it--and a hacker can get at either (even if it's in the keychain.) If you require a network connection and use a key generated from something server-side and client-side... well, an attacker can just spoof the request and get that server-side component anyway.
So it really depends how secure you want to be. If you just want to keep honest people honest, simple encryption is often good enough. If you want to make a bulletproof DRM system... you'd be the first to accomplish it.
You can use Encrypted Core Data to secure your data.
This library actually decrypts your database at runtime. You can leave your PASSCODE in your .m file. (My assumption is that it is difficult to get the hardcoded PASSCODE from the object file)
And as #jonathan put it, if some person is desperate to get your data, they will.
EDIT:
As Zaph mentioned in the comments section, do not try to put password in your code either directly, or by obfuscating them in your code by some logic, as any one who is desperate to get your key could reverse engineer your binary and get it.
Is it possible to reverse-engineer my iPhone application?
Yesterday I posted this question about protecting files: Protecting the app sandbox
As mentioned, it appears that this is effective for protecting a file if the user has a passcode on the iPad. Naturally this raises the question of how to handle the encryption if the user does not. Now I have an idea, but am not sure if it's feasible or not.
Is there any way to override the encryption key to use a custom one? My gut instinct is no, but I figured there may be a way. (Btw, this is just an experiment for fun, I don't plan on submitting this to the app store...) My application has a login, and it would be very handy if this could be handled at the application level to accommodate users that do not have a lock.
However, I suppose it wouldn't be unreasonable to disable the saving feature if there is no device passcode... Any thoughts?
You can generate encryption key, based on login/password, this allowing user to open his files only if he know password. However, you'll need provide ability to restore data in some way if user will forget his password.
I'm storing some healthcare data on a mobile phone and I'd like to know what the best system of encryption is, to keep the data secure. It's basically a bunch of model objects, that I'm serializing and storing using NSKeyedArchiver / the equivalent on Blackberry (the name eludes me for now)
Any tips? I don't want to make up security protocols as I go along, but one of the other threads suggested the following approach.
Generate a public / private key pair
Store the public key
Encrypt the private key with a hash of the user's password.
Use the public key to encrypt the byte stream.
Decrypt the pvt key, keep it in memory, whenever the user logs in, and decrypt the stored data as needed.
Is there a more standard way of doing this?
Thanks,
Teja.
Edit: I appreciate it that you're trying to help me, but the things currently being discussed are business level discussions, on which I have no control of. So rephrasing my question, if you ignore that it's healthcare data, but some confidential data, say a password, how would you go about doing it?
There might be an easier way for secure data storage. With iOS 4.0 apple introduced system provided encryption of application documents. This means that the OS is responsible for doing all the encryption and decyryption in a fairly transparent way.
Applications that work with sensitive user data can now take advantage of the built-in encryption available on some devices to protect that data. When your application designates a particular file as protected, the system stores that file on-disk in an encrypted format. While the device is locked, the contents of the file are inaccessible to both your application and to any potential intruders. However, when the device is unlocked by the user, a decryption key is created to allow your application to access the file.
So only when your app is active, the files can be read back in unencrypted format. But the nice thing is that they are always encrypted on disk. So even if someone jailbreaks the device, or backs it up, the retrieved files are worthless.
This was probably introduced to conform to some specific data security standard that is required. I can't find that anywhere though.
For more info see the iOS 4.0 release notes.
http://en.wikipedia.org/wiki/HIPAA
Make sure you read and understand this!
edit: Sorry, didn't even bother to check to see where the OP is from, but even if they aren't from the USA there are still some good practices to follow in HIPAA.
HIPPA is a business practice and total system level privacy/security regulation. As such, an app can't comply by itself on random hardware for a random user. You need to determine how your app fits into a client health care provider's total regulatory compliance process before you can determine what algorithm might be found to comply with that process.
My best advice would be, don't store sensitive data in the user's mobile phone.
If that is not an option for you, then some kind of public/private key encryption, such as one you described, would be the next best option.