There are personal service need encrypt user's data only archived by his password which able to make database saved as secret data.It is meaningful I can make sure the software developer and manager can't get users data.
It's easy that I can choice a algorithm to let user's password as factor link it to the encrypted data.But how about user change his password? On the one hand, I can't save user's password straightly(password encrypted by md5 which is irreversible), on the other hand, I can't encrypt data again if password changed.
Does it able to do?Thanks
UPDATE
I hit by the situation when user forget his password.It seems my presupposition was unreality.>_<
Please consider it I haven't think of any idea.
Make the question fallback to "How to use encrypted data in database make sure only data owner can achieve it."
If not consider forget password, #samgak give a good idea at question comment.
And now, can I continue use users password as the key or find another way to deal with the new problem?
Related
I want to show the password from database which is encrypted.
How to show envrypted password in admin dashboard page?
I have seen laravel documentation fo rehashing but i am not understanding it
Laravel hashes passwords, which is irreversible. You pretty much can't ever see a password once it's been hashed and stored in the database, and this is by design. It isn't encrypted, and thus, cannot be decrypted.
When someone signs in to the application, their password is HASHED, and then compared with the hash in the database. This is done so that a password can not be stolen from the database.
Now, I don't know your application or your circumstances, but I would consider it very bad practice to allow even an admin access to users' passwords (there shouldn't be a reason in the world they need to see those).
Here's a great video on the matter.
But if you REALLY still need this to happen, consider a making a custom authentication driver that at least uses encryption instead of hashing (but again, probably a bad idea). I found a few different tutorials with a quick google search.
I'm developping an application with Spring MVC, and I want to add the security aspect to my authentication.
In my application I have the login and the password are registred in the database and any one who has access to it can see the login and the password clearly.
I want to have data encrypted in the database so that I will be sure that no one can use or divulgue them .
I've searched in the net but I found that there are some algorithms which may encrypt data such as md5 ,but the problem it's irreversible.
Could some body help me ?
I agree with Danny H, but wanted to address the other half of your question too: protecting the login (usually an email address). Most people ignore the need to protect it, but for website that want to maintain secrecy of their customers (not just Ashley Madison but also medical websites), then you'd want to add a layer of protection for the other data.
First, a reference on protecting the password: Secure Salted Password Hashing. Use either bcrypt, scrypt, PBKDF2, or argon2.
Now what about protecting the login? You can actually do a similar thing for protecting it, but you will need a fixed salt for it (for passwords, the salt must not be fixed!). Let's assume bcrypt is used for my example below.
Consider how the user would login: User enters his login id and password. System applies bcrypt to login id with fixed salt to look up user in database. From that, system gets the user's password salt, and system computes bcrypt on user provided password with salt to see if it matches hashed password in database. If so, user is granted access. Therefore, system granted access without storing the user’s login id in plaintext form in the database.
What about user forgetting password? No problem if the login id is the email address: the user enters login (email address) on forgot password page, system applies bcrypt with fixed salt on user entered email address to see if the user exists in database, and assuming yes, then emails the user a secret link for password reset. Within the database, we have to associate that secret link to this user to make sure he only resets his own password (not somebody else’s!).
What if the database is exposed? Anybody could determine if a specific user is in the database by computing bcrypt on that user’s email address and looking for a match in the database, but nobody is going to be able to reverse the entire collection of email addresses, which is a big improvement over the present situation.
I discussed this idea in a blog of mine more than 2 months ago, see: https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/
Why is it a problem that the encryption of passwords is irreversible?
When the user creates an account, salt and hash their password before saving. I prefer using bcrypt.
When the user logs in, you can use bcrypt's checkpw to compare the users credentials to the hashed ones saved in the db. Having them irreversible(undecryptable) ensures that if someone gains access to your db, they don't get all of your users passwords as well
I haven't used BCrypt with java before but I just glanced over this tutorial and it seemed like it may be a good starting place for you
Edit : Just realized he was using jBCrypt but the differences in the two should be very minimal
Edit2 : Here is a pretty good article on cracking passwords that are found in the database and a reason I recommend bcrypt and why you should use one-way encryption
MD5 is a hash function which is not reversible - it is not an encryption function. Hashes give the same output for a given input every time, that's why they work. Hashing would work in the scenario you described because the users who could see the hashes wouldn't know the original password - that said, it still sounds like a bad idea.
Ideally you would hash the passwords then encrypt the hash and other users wouldn't be able to see these values encrypted or not. That would be my suggestion, but if you choose only to encrypt the passwords RSA encryption would work just fine.
I've got a Codeigniter app that is an extension of an old phone directory my company used to send to employees. So for people who want a print out they had me create a method for "printing" that was a bit more robust than simple HTML to paper. The app has the user download a PDF. However, they also didn't want the PDF easily readable so they had me password protect the PDF with the user's password. This all worked fine in the world of terrible security (storing the raw password in the database)...
Now though I've implemented PHPass to hash all the passwords and this breaks the PDF generation portion. When using $this->pdf->SetProtection in Codeigniter the only thing I can pass in is the hash. This of course does not match what the user is trying to type in after the PDF is downloaded.
Has anyone had any success with modifying how a PDF processes passwords before checking with what's provided in the PDF? So far the only solution I've come up with is to ask them to enter their password again before download but I'd really like to avoid this extra step. Please let me know if you need more to go on. Thanks!
What you are trying to do is impossible. The purpose of hashing is to prevent exactly what you are doing. Hashes are a one-way algorithm meaning that once the password has been hashed by PHPass you can't obtain the original password without a dictionary attack or a hash table.
There are a few alternatives however to allow you to implement this, all with varying levels of security.
New Password
The most secure is as you said to have the user enter a new password when they download the PDF which is passed to TCPDF.
Cache the Password
Another alternative which is slightly less secure is to cache the user's plain-text password in the Codeigniter or PHP session on login. You can then use the password stored in the session later on when you need to add a password to the PDF. Personally I would use the PHP session and not Codeigniter because Codeigniter stores its session userdata in a plain-text json array in the sessions table of the database while PHP does not.
function loginHasCompleted() { $_SESSION['password'] = $_POST['password']; }
Encrypt the Password
You can also encrypt the password in the database instead of hashing it. By encrypting it with something like AES-256, you can decrypt the password again to use it in the PDF generation. This does pose some security concerns however because if an attacker obtained the AES key used to encrypt the passwords said attacker would be able to decrypt all of the passwords as if they were plain text. It's more secure than plain-text passwords as the attacker would need to obtain both the database and the hard coded key in the source code, but it is still a concern.
I have an command line application (not rails) that needs the user to provide their username and password for the website the cli accesses.
I don't want to make the user enter their details for each and every command they execute.
How do I store the details without compromising security and storing the details without encryption? If I encrypt the password, where should I store the pass key so it is still secure?
I imagine an implementation similar to the way the Heroku gem works would be good.
UPDATE:
So I have gone ahead and implemented this in my application, but something doesn't feel quite right about the solution yet.
Prior to accessing the website for the first time, the user is prompted to enter their username and password. Following successful login, the user is asked whether to store the details for later. If yes, the password is encrypted using a key - however, as this is a ruby gem, the key is stored in the application in plain text.
Is there another way to do this. The file containing the username/password is now secure BUT the key to unlock it is stored in the application code.
On the update: no. If you need access to the plain text password, you can only obfuscate the password. You cannot safely store it. The key needs to be in plain, or the key that encrypts that key needs to be in plain, ad infinity. Can't be done.
Currently I am developing an application with 3 roles: 1 for customers, 1 for the company employees and another one for a Super Admin.
Is it a good practice to allow Super Admin users to see/edit the users' passwords through the UI? Or should it only be modified directly through the DB?
UPDATE: I am using asp.net membership provider and MySQL. Therefore, there is a table in the DB called my_aspnet_membership which stores two fields: Password and PasswordKey. The field PasswordKey seems to be the encrypted password. However, the Password field is stored in plain text. So, can anyone tell me why this is designed in this way if it is not a good practice? Thank you all for your responses!
UPDATE: For those who asked if it really stores the password in two different fields:
Your password should not be stored un encrypted inside your database and as such, shouldn't be visible to users of the UI nor the database.
As for whether it should be modifyable, sure.
In this case the password should be re-generated through user or administrator request. Again, this should be encrypted in the database. My preference would be to auto generate the new password for the user rather than have an administrator type it themselves.
Given this, the only way to change the password directly in the database would be to encrypt it first before insertion. It's quicker to do this through an UI that deals with the encrypting.
UPDATE
In answer to your update, you should specify in your web.config that the password format be hashed:
<providers>
<add [...]
passwordFormat="Hashed"
/>
</providers>
as outlined here:
http://msdn.microsoft.com/en-us/library/ff648345.aspx
There is never a reason to allow someone to see a password they do not own, under any circumstance.
Update for the OP Update: Of course I have no way to know why your DB was designed like this. Thinking optimistically, it contains the plain password so that if a user forgets their password it can be mailed to them -- a bad excuse, but an unfortunately common one. A better alternative is to have the system mail them a freshly generated temporary password -- one which works only to allow setting of a permanent password (and does not destroy the current password until the change occurs).
No user should be allowed to see the Plaintext password of any other user whatsoever. The password must be encrypted atleast if not hashed even in the database.
You MAY allow the super admin to change any user's password, but allowing him to see it in plaintext is taboo.
EDIT: Are you absolutely certain the password field stores the password in plaintext, while there exists another passwordkey field? Because, it sounds similar to a 'salt' mechanism to me. Where, the password is first encrypted with one key, and then re-encrypted with the passwordkey field.
EDIT 2: I am now almost absolutely certain that your database is using a salted password. Salted passwords are often used to increase the security level of the database. For more information on salt, check this.
You should always save passwords encrypted. Therefore you don't have any possibility to show the superadmin the password of another user.
You should never ever store password as is in any database. Always use a hash function to save the password.
You should save all passwords encrypted in DB.. Not in plaintext!!