I have a ASP.NET MVC membership project, now I have been given the task to implement a memorable word.
I have done some research and have got nothing in the last couple of weeks, so looking here for some help.
I have http://www.asp.net/web-forms/tutorials/security/admin/recovering-and-changing-passwords-cs and its corresponding links and most of the it talks about of a question and answer
RequiresQuestionAndAnswer
Its not what I need exactly, here is what I need,
When creating a user I accept a 6/8 letter memorable word
Every time I log-in I need to ask any 3 characters from the memorable word and they have to match
If the entered characters are wrong, he will have to try to re-enter the same 3 characters for another 2 more tries after which I will lock his account.
Is there a provision to do it? or does it have to be implemented?
Do you ask for a password in addition to a memorable word? If not, you could use the password property in the membership provider as your memorable word.
You will have to change the passwordFormat to Encrypted or Clear (I recommend Encrypted). Then, when the user tries to sign in, you get the password for that user. (This is why the password can't be Hashed, because a hashed password can never be decrypted to its original value.)
Once you have the password, it should be a simple algorithm to compute whether or not the password contains the 3 characters entered. If it does not, return a validation error. If it does, write the authentication cookie and redirect.
Update
Since you are also asking for a password, I don't think you will be able to use the membership provider for this requirement. You will have to implement it separately from the provider.
Related
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.
I am writing a Mac OS X Dashboard Widget for Pastebin.com and it stores the user's password (my code does not encrypt it) using widget.setPreferenceForKey.
Is it safe and good practice to do it this way?
I know this is an old question, but I'm trying to develop a Dashboard widget myself at the moment, and I've run up against the same question. I'll share what I've learned.
First of all, the good news is that you don't necessarily need a plugin; all you need is to give your widget access to the command line.
OS X actually includes a command-line utility called security, which lets you do all sorts of things involving the Keychain. You can read up about it by entering info security in Terminal. I haven't reached the point where I can test this from within the widget itself yet (only in Terminal), but from what I've gleaned, I think this is what you do. Anyone who knows better, please don't hesitate to make changes.
Storing the Password in the Keychain
Assuming username and password are variables we've already set up:
widget.system("/usr/bin/security add-generic-password -a \""+username+"\" -s \"My Awesome Widget\" -w \""+password+"\" -T \"/usr/bin/security\" -U);
Command Breakdown
/usr/bin/security: the widget.system() method requires the full path to the command we're executing. This particular command lives in /usr/bin.
add-generic-password: one of security's many commands. There are other kinds of password items that can be added to the Keychain, like Internet passwords, but I think the generic type is best for this case.
-a: the "account name", or username, which goes with the password we want to store. The Keychain probably won't be the primary place you store the username, since we need it to look up the password later, but if a user has multiple instances of our widget open, each with a different user/pass combo, including the username here will let us specifically look up that password when the time comes. Quotes aren't strictly necessary, but you should include them if usernames for your widget are allowed to have spaces.
-s: the "service name" for the Keychain item we're creating — in other words, the verbose, human-readable name. Your widget's name would probably be most appropriate here.
-w: the password. Again, quotes recommended if your passwords might have spaces.
-T: the path(s) to any application(s) which are allowed to access this Keychain item without question. Without this flag, any attempt to retrieve the password later will result in the user seeing one of those "security wants to use your confidential information stored in "My Awesome Widget" in your keychain" prompts, and chances are they won't know what it means and it'll freak them out. I'm assuming here that because the widget uses security to request the password, security (and not, say, DashboardClient) is the program which needs to be granted access.
-U: tells security to update this Keychain item if it already exists, instead of just failing.
Getting the Password Back from the Keychain
This involves an extra step after you get the password, but it still shouldn't be too bad.
var messyPassword = widget.system("/usr/bin/security 2>&1 >/dev/null find-generic-password -ga \""+username+"\" -s \"My Awesome Widget\"").outputString;
scrubPassword(messyPassword);
Command Breakdown
/usr/bin/security: hello again, officer. Some weather we're having, eh?
2>&1 >/dev/null: the output of find-generic-password includes reams of crap otherwise potentially useful information that we don't need in this case. Fortunately, it outputs the password separately from all that, so it can be captured on its own using this extra bit. (Thanks to Allan Odgaard of Macromates Ltd. for his blog post detailing this trick.)
find-generic-password: the counterpart of add-generic-password. The arguments which follow are used as search criteria.
-g: tells security to actually, y'know, output the password. Otherwise, I guess it just...acknowledges the fact that the item exists, then quits?
-a: the username which goes with the password we want to retrieve.
-s: the human-readable name we picked for the widget when we wrote the add-generic-password command.
Wait, what's scrubPassword()?
Well, the catch is that even after all the other stuff is stripped out of security's reply, the string you get back isn't just the password. It's more like:
password: "nobodywilleverguessthis"
As far as I know, we have to use regular expressions to crack open that string and get at the shiny, password-y pearl within. I don't know about you, but regular expressions are the stuff of nightmares for me, so I was very relieved and excited to find txt2re, an online tool that lets you reverse-engineer a regular expression out of the string you want manipulated. You can literally just paste security's output into txt2re and grab a chunk of JavaScript that'll extract the password from it.
Note:
widget.system() also allows for a handler function to be used as a second argument, so it's possible that you could call your scrubPassword() function right there and skip the whole part with the messyPassword variable. As I said, I've only tried calling security from Terminal so far, so I don't have any experience actually working with widget.system().
Removing the Password from the Keychain
When an instance of the widget is closed, we probably don't want to leave the associated password cluttering up the user's Keychain, so we'll do the responsible thing and pick up our litter. This one is a bit simpler than the other two commands, since we don't need to create anything or get anything in response.
widget.system("/usr/bin/security delete-generic-password -a \""+username+"\" -s \"My Awesome Widget\"");
Command Breakdown
/usr/bin/security: the usual.
delete-generic-password: does what it says on the box, using the following arguments as search (or, rather, search-and-destroy) criteria.
-a: the username corresponding to the password you want to take out.
-s: the human-readable name of the widget.
Hope this helps!
No. The password would be stored unencrypted in a property list. As far as I know, there is no direct way to securely store information from a widget. The only thing I can think of would be to use a plugin to store the password in the user's keychain. See the Widget Plugin Interface and the Keychain Services Reference.
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...
On most sites on the register user part they want you to enter password 2 times.
Why is that? Why not just one input where you enter password? Why do you have to "confirm" it.
You know
Username
Password
Confirm password
Submit
This has been on my mind for a while...
Hope somebody can answer this.
Thanks
It is to avoid typos. If you have to type the password twice chances are you'll make your password what you want. They want to avoid having people whose password is "blah" having to retrieve their password later on because they typed "blaj" by mistake. This is especially true since password fields show as asterisks (*********) and sometimes it is hard to tell if you typed what you thought you typed - people are likely to make typos without even realizing it. Some websites do this too with the email address when it is essential that is correct as well.
By the way: I am not sure why PHP is mentioned at all, this has nothing to do with PHP and is used in all kinds of websites. :)
If you use an input element of the type password (that you should!) the entered text will not be shown. Instead every character is represented by a * or • to at least get a feedback for the length.
So you cannot see if you spelled your password correctly. Therefor you are asked to enter your password twice and the application checks if both entered passwords are identical.
But this doesn’t prevent that both times the password is entered incorrectly.
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.