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.
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 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.
I'm writing a very simple login system for a Rails app. I'm using RESTful authentication. It's a fairly conventional setup, where I'm sending the email and password to authenticate the user.
Here, I used REMEMBER ME?, if same user again wanna login then by using cookie, user can re-login. Now thing is like, I want to print email and password in its respective text-box. Email is inserted into the textbox but I am facing a problem to show password in text-field.
At the time of login, such condition is used
#person.password_hash == BCrypt::Engine.hash_secret(#password, #person.password_salt)
How can I get my password in text form?
[irony]Why are you even hashing them if you want to display it in text form?[/irony]
But to be serious: hashing is one way operation, you can't revert it.
http://en.wikipedia.org/wiki/Hash_function
Therefore you can't display user password (and btw - you shouldn't do it anyway, it's violation of the security principles).
When writing "remember me" feature, look at way devise is doing it: http://rubydoc.info/github/plataformatec/devise/master/Devise/Models/Rememberable If you want that feature to be really safe, there is some amount of work required to code it.
After a lot of searching the web, I found that BCrypt::Engine.hash_secret is one-way encryption of password. This means there is no way to reverse the process. So if you are trying to make password text from BCrypt::Engine.hash_secret, you cannot do it.
I haven't had to tackle a login process before so this is new territory for me and all I seem to be finding on Google are conflicting methods of handling this process, so I was hoping someone could help clarify.
So far I have a salted SHA1 hash made from mixing username, password and my salt variable.
When the user logs in their credentials get hashed, then this hash gets sent to sql and if found comes back with a UserID (or something). So I know they are authenticated.
With that I can handle their session with session variables.
Is that right so-far?
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
I'm confused, can anyone shed some light?
Thanks in advance
You are usually better off using the authentication methods provided by your platform than creating one yourself. There are a lot of non-obvious problems that you can easily leave yourself open to. Which platform are you using? Are you using a web framework?
General purpose hashes like SHA1 are inappropriate for password hashing as they are optimised to be very quick, when you want something that is very slow. For discussion of this, see How To Safely Store A Password.
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
Hashes are designed to be one-way functions, so no, it isn't the same as putting their username and password in plain text. However if you do it that way, you'll have to create a way of letting somebody authenticate with the hash instead of their username and password, and that is the same as storing their username and password on the client (as far as you are concerned, anyway).
I like the fact that you have used salt for your hashing but I don't think it's necessary to use the username for hashing only password+salt should be enough. Specially it will inflict an overhead of rehashing if you want the option of changeable usernames for your system.
For remember me option, I don't think you should store any credentials at client side cookies. Only the session ID should be enough. If you want to make it really secure you should use client-side certificates that are issued by the server.
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
Your first login process is correct and up to todays security standards with the only exception that you may want to choose another hashing function over sha1.
Sha1 is very quick and therefore brute force attacks to crack a hash are faster. So if your hashes (database) and token (source code) get leaked, the passwords can be cracked.
One countermesure is to use a slower hashing function (see Jims answer for an article about that)
But the best of course would be not to leak your hashes in the first time.
A possibility for the remember me function is to let the user keep the session cookie for longer. For example Magento and Zend Auth does this.
This is however very ugly because you are likely to get hundrets of thousands of sessions stored on your servers, even for users that never return.
The far more elegant way is to store this information client side.
Sidenote: Of course you shouldnt put too many cookies on the client because they get transmitted with every page request. But a login cookie is a very valid case to do so. A good practice is to store the login cookie at the client side and populate the server session with data saved in a database at login which is marked in a session. This way you eliminiate continous database requests and have a good user data registry. Of course write has to be done to the database and session directly or better to the database and then somehow flushed to the application (full or incrementally).
Putting the hash in a client cookie isnt like "plaintext". However its ugly and awful and insecure on many levels.
There are some different approaches but they mostly involve some hashing again.
The most common and easy one is something like to put a cookie with user_id=john and user_token=HASH($userid.$appsecret) on the client. Or to store them as one in one cookie.
This is kinda secure but I prefer the following method:
Generate a string that holds:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Run it through a good hashing function and store a cookie at the users client that looks like
auth=userid;timestamp;hash-of-the-above
When the client logs in via cookie you re construct taht string from above but take the timestamp and user id from the cookie. Generate the hash and see if it matches. Then you have validated that it is the cookie you generated for that ip adress segment and this user agent at the specified time
Sidenote: first two ip segments rarely changes with dynamic isps. you can leave them away too, its for extra security.
What is the main advantage of thsi method?
The client or you can invalidate all login cookies by setting a timestamp. Only cookise that have been generated afterwards are accepted. You can also implement a timeout.
This is good if you want to "remote logout" form a public computer where you forgot to log out or something.
I think functionality is very important and with this method you dont have to keep track of single login cookies (like google does).
Hope this helps you.
You can scale this method to any level of security you like and adjust it to your needs.
your authentication is just fine. If you want to make it even more secure you could transmit the login information with a SSL encrypted connection so nobody can read what's going across the network.
The remember token is quite simple let's say you want a remember me function that is valid for 14 Days.
A stranger with no authenticated session comes to your site:
Check if there is a remember me token in a cookie
If yes, check if you can find this remember me token in your database and check if the "valid until" column is still valid (date comparison)
If you find a valid token you can set the user id and authenticate his session
If you don't find a valid token redirect the user to the login page if necessary
When the user fills out the login form and authenticates him sucessfully:
Generate a token using an appropriate hashing function. The token you hash could look like "[Timestamp]---[userpwd]" so it's (almost) definitely unique! Save the token and the date until the token is valid (+14 Days from now as example) to your database connected with the user's id. If there's an expired token, replace it because you don't need to store expired tokens.
If the user logs out by clicking the logout button or similar just delete the token record in your database and the user's cookie.
That's it!
If your platform (web server etc) supports HTTP digest authentication, i would strongly advise you to use it. It was designed by people who know more about security than either of us ever will. It doesn't send passwords over the network. It is supported by all modern web browsers, including mobile devices. If the browser has the password stored, it happens transparently during connection, giving you the 'remember me' functionality without needing to go anywhere near a cookie.
The only thing it doesn't do is let you use a nice form - the use will get a dialog box from their browser to log in.