I am trying to make an AppleScript program that asks the user to input their password and check if the text returned of the variable is equal to their real password. I am not trying to gain administrator privilege, just trying to retrieve the user's password and store it in a string. The reason why I bother to check the variable against the real user password is I don't want the user just enter something random. Are there any ways to do this?
Thank you!
In short, you can't. I have looked into this quite a bit, and there is no way you can get the users pass. If you could, you could destroy their computer with a simple script. The "Keychain Application" keeps the passwords far away from any kind of script. Sorry to disapoint. :(
if you could, it would be like this:
set realPassword to administrator password of (get system info)
set theirPassword to null
if realPassword is theirPassword then
say "yay"
else
say "nope"
end if
Related
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.
Say that I have simple command line application, that looks something like this
# solution.rb
puts "Enter your password:"
password = gets
if password == "secret"
puts "you're logged in"
else
puts "wrong password"
end
and I need to create a script, that will test if it works correctly. I don't want to test the code itself, only it's user interface.
It would be a kind of homework checker, where a user can submit a script which is supposed to handle a certain task in a certain way, and this script will test it with given inputs.
The idea is, that I would run something like
ruby tester.rb solution.rb
and the tester.rb would first run it and pass secret and check if it got you're logged in as a response, and the same thing for the second case.
What would be the best way to achieve this?
I highly recommend you check out cucumber with aruba, which is specifically designed for this sort of thing.
There's a quick intro which might be a good place to start.
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.
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.