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.
Related
I have an application and I want users to have the ability to create a user instantly without even having the page to reload (So that if they are in the middle of something they dont have to stop). I have used ajax for similar things in the past however I am a bit scared using it for something like users with passwords (I am using hash salt and pepper but still, im a bit paranoid). Are there any security issues with that?
Using AJAX is not a problem.
Using hash, salt, and pepper is fine, but do you check user's email address for receipt? You can send a six-digit number to the email address entered by the user, and ask the user to enter that number on the input form to confirm that the user can use the email address.
I would need a readout of joomlas user password in plain style to give special users the ability to send a mail in a custom module with login details like:
https://mydomain/login?user=testuser
password = testuserpassword
For that reason I need the plain passowrd out of the DB. Is there a way to show/read out password from joomla-db in plain style?
Thx in advanced!
Joomla saves the passwords in the database using a one way encryption mechanism, which means that you cannot know what the password is.
I am sure what you're doing can be done in a different method - if you want to login users automatically once they click on a link then you can have a different authentication plugin that will use a random, unique, one-time-use, and time-sensitive hash that will be associated with a Joomla user account.
You need to create a plugin with function after joomla user save
you need to store password in another table with user id and then you can use with sql query to get password.
This is a bad idea for the following reasons:
email is sent in plain text
email often is stored on several systems along the way to your mailbox
email often is stored on your computer in plain text or other unencrypted format
many copies may exist in many places, even after "deletion"
even encrypted email can be broken in to, given enough computing time
your account's security may have been compromised even before you read your email (changing the password will not help in this case)
However, you definitely can email the user their password upon initial registration by going to Global Configuration > Users and setting Send Password to "Yes" (default setting in Joomla 3.x).
If you are looking for a way to send this password after the registration event, as others have mentioned, you are out of luck. What Joomla! provides is a secure password reset functionality to reset a password to something the user can remember. This will be the best approach for you, as well.
Resources: Sending Passwords in Email, Stop Joomla Sending Passwords in Emails
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.
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.