I am creating a small Sinatra application which will have login functionality. This would be the first time I have done this in ruby and wanted some advice when posting passwords from a html form. What would be the best and most secure way to do this.
Any help would be most appreciated.
Thanks
Alex
Posting password from a HTML form in a secure way is not, exactly, a Ruby/Sinatra issue. It is a set of best practices take on all components of your stack.
As long as I remember, these are the items that come to my mind:
For transfer sensible data always use HTTPS.
Never save clean password on your database. Always use a Hash algorithm with salt http://crackstation.net/hashing-security.htm.
Impose some constraints to the password, like: minimum length, force letters and numbers, etc.
Avoid to log sensible data (e-mail, password).
Related
So I'm working on my own website with my login system.
I am working on the password storing part and have been looking at a couple of youtube videos where peoples tell me not to use things like md5 because it's outdated.
I looked at the video Tom Scott made about how NOT to store passwords and he told us to look up a recent tutorial on how to do it properly.
For my project I really need to store the passwords myself and not use anything like Facebook or Google for logins.
I looked at a lot of websites and questions here on Stack Overflow but can't seem to find anything from this year where it is all explained.
So now I'm wondering what is the best way in 2017 to store passwords?
Do I need to use a Salt and a Pepper? Maybe something else? And which hashing algorithm is the best at this moment? If possible I'd like to use this within php.
Can anyone help me out with these questions?
Thank you :)
I assume that you just want to store passwords for user authentication, and you asked for a PHP solution explicitely, so the answer must be to use the PHP function password_hash(). This function is up to date and handles all the tricky parts of password hashing.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
If you are interested in more indept information, you could have a look at my tutorial about safely storing passwords.
Hi I am building an Internet website with Java and Spring framework. I believe my question is not technology or framework related.
I need to have links in user interface so that visitors can click and to see records. These links have the format of
http://mysite.com?id=number-id-or-random-unique-string
Not all records are allowed to view. For the ID parameter in the URL, I could use the database-generated number as the ID value and so I do not need to have additional programming. Or I could use unique random string (for example: jcTDjhdDUls) as the ID value (I have to program this part). Numbers allow curious people (with good or bad intentions) to EASILY guess and try other IDs. Unique random strings seems better in this regard.
However, no matter numbers or strings as the value for the ID, I have security check in the backend code to see whether a visitor is allowed to see a record. From this perspective, I am not sure what is the real benefit of having random string as the ID.
I hope to have input from experienced people. What design decision do you choose? Or other better ideas?
Thanks and regards.
You certainly can if you want to, but I would not go through the trouble to randomize the ID. This is at its root, "security through obscurity (STO)." Sometimes STO is useful, but in this case I don't think it is worth complicating and bloating the code and memory footprint. It's surprisingly easy to enumerate the valid IDs whether they're randomized or not, using a tool like Burp Suite. All the security controls that really matter should be implemented in the backend.
What is safer?
I can use either one as I'm using CodeIgniter, but with Sha1, I can't reverse if I ever needed to for some odd reason like I can with encryption.
But I'm still somewhat new to PHP, so if there is a way I can possibly do something like display the sha1 hashed password as stars, so if say your password is "lala123" it would show this to me: "*******" and never ever be able to be shown "lala123", is it possible to do that with sha1? If so, please help me, otherwise I'll use encryption, but only if it's safe to use for passwords. Please let me know :)
Hashing is considered more secure for the very reason that even you cannot restore the password. If you password database is compromised, and the password encryption is reversible, the baddie might decrypt them, especially if the code that does the decryption has been compromised as well. SHA1 is not reversible by design.
You're not supposed to display the password in the UI - ever. The * are just that - an arbitrary number of stars. Disclosing the length of a user's password constitutes in itself a considerable hint to a would-be guesser.
Neither. You should use hashing to keep the passwords secure in case someone gets the password database. But the consensus answer seems to be to use bcrypt, described in this answer. It is a hash function based on blowfish with variable cost so you can tune security versus performance.
Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:
Digest::SHA1.hexdigest(salt_plus_plainpassword)
Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?
The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.
It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.
The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...
I'm implementing a password + password hint code I and want to prevent the user from making the password hint reveal the actual password right away.
Here are the scenario that I want to prevent:
Lets say that the password is: foobar123
Then the password hint can't be:
"foobar123"
"The password is: foobar123"
"f-o-o-b-a-r-1-2-3" (or any other x len separator)
"f00bar123" (replace o with zeros)
several questions:
Am I going overboard with this? Should I just let users pay the price for being security unaware?
Am I missing an obvious scenario that I need to prevent also?
Can each scenario be evaluated using regex? This is the most extendable method of adding future checks that I can think of.
I would simply give the user a fixed set of questions to choose from, to which they supply the answer. In this way you are never exposing user input values, only the user's selected value from your pre-canned list of choices. This would avoid your problem entirely.
Alternatively, if you have the user's email address, you could simply have a password reset that sends a link with an encoded key that allows a one-time password change. This way you need not provide a hint, simply a means of changing the password in response to one of these single-use tickets.
If your threat model makes password hints acceptable, I think you're going overboard with your meticulous password exposure prevention.
However, if your threat model doesn't make them acceptable, but you're being pressured into offering the feature, then be as fascist as you can.
Finally, don't limit people to canned password hints. They're extremely annoying. They imply that you know what is and isn't public knowledge in my life. Most of the sites I notice canned-only password hints on, offer hints that are all a matter of public record.
Good luck!
Personally, I say you are probably going overboard. But it somewhat depends on both the severity of compromised data (e.g. is this a web site to vote for Ms. High School or is it a web site for high-end auction house or is it a web access form for CIA?), the amount of users, and the likelihood that anyone would sue you for negligence in design after using bad hint and having their access compromised.
You can do the regex for the most dumb ones (e.g. take 6-character sub-strings of the password and do a match of those sub-strings in the hint), as well as character count for the smart ones. E.g. if the hint uses 60 to 80% of the characters in password (by count), reject it.
An even more nuanced solution is to count with position, e.g. count "o" only if it comes after "f". but this is probably overboard too.
Also consider non-hint solutions (multiple choices, non-verbal hints, e-mailable password change requests)
Does it need to be a hinting model?
The way I've done this in the past is to:
A- Have a security question.
B- Have a captcha.
C- Provide a new temporary password to an email on file only that must be changed on first use.
You can't prevent users from doing something dumb. No matter what protections you put in place, they will find a way to get around them. For example:
"321raboof backwards"
"foo and bar123"
"foobar (124 - 1)"
I don't believe there's a deterministic way to generate a hint, unless you're limiting passwords to something like birthdays or given names.
But they wouldn't be strong passwords would they?
Let the user suggest a hint - and pay the price for an obvious one.
Give plenty of advice that the hint shouldn't be obvious, but I think it must be up to the user to decide.
It's not your problem if they compromise the security of their account. Save on unnecessary coding and testing, and just don't worry about this feature!
I am about to change our password hint model to one with canned choices. To those who said it's the users own problem if they put a stupid question and answer I would mention that it become the problem of those who work for our help desk tech support. That's what we'e trying to avoid.