Is there a way knowing what hash-algorithm is used?
My question is grounded of that I've got an database from a customer with some users and passwords. I have no idea what the passwords are (so it's correctly stored in the database) and the customer would not like to give these passwords away (it's understandable)
I have access to the database and I know that the passwordhash is 60 characters long, but nothing else.
I basically want to create a new user (directly in the database if possible) with a temporary password so I can login to the system - but it's kind of impossible if I don't know how to create the password. Any thoughts?
The system is created in CodeIgniter but I don't know what authentification-method is used.
What data do the passwords contain? Do they contain only 0-9 and a-f, i.e. hex
values, or can they contain other data too? If you want to know the algorithm, it is crucial to answer to this question.
If they contain hex values only, 60*4 = 240 and there is no common algorithm
which gives a hash that is 240 bits long.
It has been suggested that the password contains salt, which might explain the
unusual length.
Why not ask the customer what has algorithm is used? It is understandable that
the customer doesn't want to give away these passwords, but there should be no
objection to giving away the hash algorithm.
Related
I am writing an app that has a sign-up form. This article made me doubt everything I knew about human names. My question is: does a person's name necessarily have positive length? Or can I validate names in this way and be confident that I have not denied anyone their identity?
P.S.: one might ask why am I validating at all. The answer is that this is for a school project and proper validation is a part of the mark. The article above proves that person's name can be pretty much any string of positive length but I don't know if zero length is OK.
With all types of programming, you have to draw a distinction between what is meaningful in the real world, and what is meaningful for your software solution.
How the data is to be used will validate what type of validation is required.
For instance, if your software interfaces with a government API, and the government API requires a first name and surname, you should do the same.
If you're interacting with bank accounts, you may have a single string which represents that account name, which many or may not be a human name or not, but may have other constraints around length.
If the name is only to be used for display purposes, maybe there is no point to capture the name at all, and instead you should capture a preferred display name (which doesn't needlessly assume a certain number of name components).
When writing software, you should target to make as few assumptions as possible, unless those assumptions will cause an increase in complexity of your software solution. If the software requires people to have non-empty names, then you should validate at the border that this is true.
In addition, if you were my student, you would have already lost marks for conflating null, and an empty string. In this instance, null would represent you lack data about the name, and an empty string would indicate that user has specified that their name is empty.
Also, if you decide not to validate something, you should at least leave a comment to indicate that you thought of it. If you do something unusual, it's possible a future developer may come along and fix the "bug". In addition, this helps you avoid losing marks.
Alright, here's the story:
I'm getting married soon, and I'd like to create a website (or an app).
Obviously, I'd like that only guests could access to it.
So I was thinking about a system where it would require a security code to sign up.
The problem is that I do not trust anyone not to be silent about the code, so I was thinking about giving a different code for every couple (or family) of invited people.
On the sign up form, I would then verify that the entered code has not already been used.
But since I don't know who will sign up to the app, and I don't really have time to manually register each guest, I won't have a database with what code has been provided to whom information.
So, I need an algorithm to generate a random security code, and the reversed one, to check if a given string is a validate security code
I need the algorithm to be complex enough so people could not guess what's the magic behing the code they received. (I know, it feels pretty paranoid)
The generated Securiy Code should be pretty simple, like 6 to 8 characters (mix of digits, upper and lower case letters)
The main issue is that I have no clue how to perform a reliable system to generate and validate a security codes.
I feel like I should have a secret key stored on the server side, that would be necessary to generate a code, and I would have to find it back if a given string is a valid code.
Let's say secret is my private key.
The generation algorithm would be something like secret + whatever = generated code (where the + whatever operation remains to define).
But then how could I check a given string? string - whatever =? secret would be the solution (where - whatever is the reverses operation of + whatever).
Well, I actually have no clue of what whatever could (or should) be.
Do you have any advice or guidance ?
For the technical part, I will probably code this in JS (with a NodeJS server).
But as I'm talking about the concept of security code generation, any pseudo-code will do the job.
Generate a hash of the person's email address (capitalized) and make the code the first n-characters. So, for example, if your email address is TOUPYE#GMAIL.COM then the SHA-256 hash would be: 038122aedbf777b8c7c3aaed14ae7c08249a9d47f82f4455a0d667cacc57d383 so your code would be "038122". Generate a list of codes for each person/family. If someone has no email address use the telephone number. If they do not have a telephone, use their address.
okay I am trying to make a log in form to my website in C# it has md5 + salt.. the problem is salt. md5 I can make work but salt just won't work. I made a php that gets the user name, user group id's etc. I have removed tons of instances of salt in the db and it either destroyed log in, or just did nothing. I am wondering if there is an easy way to remove salt?
What do you think is the purpose of the salt? If you could easily remove it, what would have been the reason to add it? You should really take a few minutes to read a tutorial about password hashing.
MD5 is not an appropriate choice to hash passwords, because it is ways too fast. One can calculate 8 Giga MD5 values per second with common hardware nowadays, that makes brute-forcing too easy. Instead use a slow key derivation function like BCrypt or PBKDF2.
To answer your question, you need the stored salt to verify the user entered password. If the user enters the password for login, you calculate a hash with the same salt you used to calculate the stored password in the database, then you can compare the hashes.
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.