Is there a way to re-validate a card using the card security code? I'd like to offer users to login with Facebook or to remember their login otherwise and I want to add an additional step during checkout to verify that the user is in possession of the credit card. I think some websites ask for the CSC again during checkout.
I could also ask for the user's password again, but I don't think that can work if the user logged in with Facebook.
Any suggestions around this?
Alright, so it seems as if this kind of verification is not currently possible with Balanced. There is no API method to re-validate a card. Here are the solutions I came up with, just in case someone else has a similar problem:
Using a different piece of information to verify the user (card expiration date, etc). But that doesn't seem very common and would probably scare away some users.
Indeed forcing the user to enter the password again. No problem if the user uses a site-local login. In case the user is logged in using Facebook, there seems to be a way to force a re-authentication: https://developers.facebook.com/docs/howtos/login/server-side-re-auth/
I have an Android app that I allow users to have a password in and "lock" the app so their friends can't look inside without their password. It doesn't use a web service or anything, and the password is stored in a private file within the app. Problem is, the users like to forget their password, then email me asking me to do something about it. Right now I can't. So what I want to do is have something that creates, and consumes a random password. The user could email me, and I could give them some random key the app could recognize, and let them in so they can change their password.
It doesn't have to be anything super secure. Any help is appreciated.
I don't think its a good idea to implement a "backdoor" in your application. THis will create a very bad taste.
If i understood correctly, you want to "unlock" the application, not knowing if the user doing this is in some way authorized. I steal a device, send you an email and you take care i can see the data. Sounds bad...
All (good) safes i know rely on the user to take care of their keys. They want security and they are responsible.
EDIT
You can provide a "security question".
Anything else i tried to construct for an "autonomous" password reset raises sever security questions (what are the authentication/authorization mechanics)
EDIT
How far are you willing to go? Assuring the possession of something (like an SMS or mail account) may reduce the issues and give some impression of security. So you can intercept SMS or mail from a PREDEFINED (application settings) account with lets say the key word "unlock". If not set, this feature is disabled. SMS interception should no be that hard.
Why don't you just build password reset functionality in the app itself? If it's not using a web service, why do you or your server need to be involved at all?
If they don't remember their security passwords, for example, your server could store an md5 hash of their password to match up their mobile device with their record on your server so you can send them a key to reset the app.
Couple of thoughts:
Is there any sort of registration process? If so, at registration time you could randomly generate a second password that you don't tell the user but just keep on file for such contingencies. Or similarly, you could offer users a "password recovery" option -- click this button to generate a backdoor password.
You could have some algorithm that generates a password from the machine id of the device and that works as an alternate password. If you were a big organization with millions of copies of your app out there, or if the information in your app was super secret, this would be a super bad idea, as sooner or later hackers would figure out the algorithm and then they could break into any machine they wanted to. But if you're a small target, it's likely no one would work hard enough to crack it.
Do you necessarily know anything about your users? Like could you generate a password from their credit card number or their address or some such? Of course this makes you vulnerable to any hacker who could discover whatever information about a potential target.
Anything like this you do you are going to create a big potential security hole: What if someone steals someone else's device, then emails you and says they lost their password? How do you know it's the rightful owner of the data? If anybody can call or email and say, Hey, I lost my password, please let me in the back door, then you have no security any more.
I want to to implement password recovery in my web application.
I'd like to avoid using secret questions.
I could just send the password by e-mail but I think it would be risky.
Maybe I could generate a new temporary random password and send it by e-mail but I think it is as risky as the above point.
Can I send a url by e-mail for example http://example.com/token=xxxx
where xxxx is a random token associated with the user. So when the user navigates to that url he/she can reset the password.
When I was in the Air Force the security rule we had was: When setting or resetting passwords, do not send the user id and the password in the same email. That way, if someone is intercepting emails snooping for passwords, he has to successfully intercept BOTH emails, and be able to connect them, to breach security.
I've seen a lot of sites that use the "go to this URL to reset your password". Maybe I'm missing something -- I don't claim to be a security expert -- but I don't see how that is any more secure than just inventing a new, temporary password and sending it. If a hacker intercepts the email, why can't he go to that link and see the new password as well as the legitimate user could? It looks to me like extra hassle for the user with no security gain.
By the way, congratulations on NOT using security questions. The logic of this device escapes me. Since the dawn of computer security we have been telling people, "DON'T make a password that is information about yourself that a hacker could discover or guess, like the name of your high school, or your favorite color. A hacker might be able to look up the name of your high school, or even if they don't know you or know anything about you, if you still live near where you went to school they might get it by tryinging local schools until they hit it. There are a small number of likely favorite colors so a hacker could guess that. Etc. Instead, a password should be a meaningless combination of letters, digits, and punctuation." But now we also tell them, "But! If you have a difficult time remembering that meaningless combination of letters, digits, and punctuation, no problem! Take some information about yourself that you can easily remember -- like the name of your high school, or your favorite color -- and you can use that as the answer to a 'security question', that is, as an alternative password."
Indeed, security questions make it even easier for the hacker than if you just chose a bad password to begin with. At least if you just used a piece of personal information for your password, a hacker wouldn't necessarily know what piece of personal information you used. Did you use the name of your dog? Your birth date? Your favorite ice cream flavor? He'd have to try all of them. But with security questions, we tell the hacker exactly what piece of personal information you used as a password!
Instead of using security questions, why don't we just say, "In case you forget your password, it is displayed on the bottom of the screen. If you're trying to hack in to someone else's account, you are absolutely forbidden from scrolling down." It would be only slightly less secure.
Lest you wonder, when sites ask me for the city where I was born or the manufacturer of my first car, I do not give an actual answer tot he question. I give a meaningless password.
</rant>
First off, do not store a plain-text copy of the user's password, or even an encrypted version. You want to only ever keep a hashed copy of the user's password.
As for recover solutions, I find that the recovery link to change the user's password is the best solution in my experience. It will probably be a bit more convenient for the user, while being largely the same from a security point of view as sending a new random password to be changed after next login. I'd still recommend having the recovery url expire after a reasonable short period of time, as well as only being usable a single time.
Hard to say what you should do, as pretty much any solution to this problem will weaken security. Unless maybe you want to investigate sending an SMS, callback verification, one-time password generators, or other such schemes that take password recovery to a different medium.
However, what you should not do:
Send the password - because after all, as has already been mentioned, you don't have it.
Generate a new temporary password - not only is this as insecure as sending the password, it also leads to the possibility of a denial of service attack. I can go to the site, pretend to be you, request a new password and then (if you haven't checked your email) you can't log in, don't know why and have to request a new new password ...
The token is probably the way to go. Receiving it notifies a forgotten password request, but doesn't take any action unless you confirm. You would also make it a one-time token with a relatively short expiry time to limit risk.
Of course, a lot depends on the application. Obviously protecting financial and other sensitive information is more critical than preventing your account being hacked on mytwitteringfacetube.com, because while it's inconvenient, if someone wants to steal someone's identity on a social network site, they can just open their own account and masquerade with stolen information anyway.
Obviously, you can't send the original password by email, because you're not storing it (right?!). Sending a temporary password (that must be changed, because it only works for one login), and a link to reset the password are equivalent from a security point of view.
I don't unnderstand the attitude towards the secret question method. It's not like I am going to make my password "BlueHouse" and then make my security question "What are your two favorite things?" and the answer "Blue and Houses". The security question is not the magic key to get the actual password. It's usually a way to get a new password sent to the email address on file. I don't know how else you guys do it, but it sounds like you do one of two things.
1) The user clicks a "I forgot my password" button and the new password is sent to the user.
2) The user clicks a "I forgot my password" button and then has to answer a security question before getting the new password emailed to the address on file.
Seems to me that option number 2 is more secure.
Why is sending a token any more secure than sending the password? If an email account has been hacked, it's been hacked. It doesn't matter if there is a link to reset the password, a token, or a new password. Don't forget, most sites don't say "The new password has been sent to the following email address for you to hack into". A hacker would need to guess the email address that needs to be hacked.
I agree with Andy. Aren't security questions normally independent of the password? (mine are) Meaning they have a question and an answer and aren't related to the password. It seems like this is used to prevent spurious password reset requests and actually does have a use.
Imagine - someone could go to a site's "forgot password" utility and enter a zillion email addresses - or just one person they want to annoy. If the password is reset at that point, the people belonging to those email addresses would have to then notice in their email the password reset and login to the site with the reset password next time they went there. With the security question, this isn't as easy for someone to do.
I see Amazon sends a link to the given email. They also require you to enter a captcha to prevent DOS attacks. Because it's a link, I imagine that means they did not reset the password immediately and it would be reset once the user clicks the link. With the scenario above, the user would just see the email and note that "no I didn't do that" and go about their business not having to change their password needlessly. A security question might have prevented the attempt at the beginning and the legit user from getting the email in the first place.
Here's a whitepaper on it:
http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
This one actually recommends secret questions as a major part of the authentication process. And sending an authentication code via email and requesting it is just an add-on layer you can optionally include.
It really comes down to how much security you want to have. One the one end of the extreme is a password reset process that involves contacting and certifying that you are who you claim to be, e.g. via id, because your mailbox could be compromised as well. Actually, as people tend to use the same password everywhere this is very likely. On the other end there is the standard approach that involves just sending out an email with a random new password.
"Secret" questions and answers are just another form of username and passwords with the fatal flaw that they are usually incredibly easy to guess, so good that you don't want to use them.
To your point about the token, I don't think it makes a big difference in overall security. Whether you send out a token that allows a user to change the password or whether you send out a random password right away doesn't make a big difference.
Just make sure the token is only usable once and preferably only in a limited time span, e.g. +24h after requesting it.
And, as pointed out by previous answers, NEVER EVER store plain passwords. Hash them. Preferably add salt.
Here's how I resolved it:
I added retrieve_token and retrieve_expiration fields to my 'users' table.
The user requests a password reset by providing their email and filling out captcha. A random hashed value is generated for their retrieve_token field - i.e. md5($user_id.time()), while retrieve_expiration will be set to a datetime that expires in next 45 minutes. Email is sent out to the user with a link:
https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570
SSL should be mandatory when authentication is required. You can also add a table for logging reset requests that stores email and the IP address. It helps track down possible brute attacks and you can block attacker's IP if necessary.
You could implement security question for requesting password reset, but I feel captcha would be enough to discourage anyone from repeating the request multiple times.
#Jay. The reason why you go to a URL to reset your password instead of just sending someone a new temporary password is more than just security. Without something like a URL with a token, a person could reset another persons password. There is no need to gain access to the email. If someone had a bone to pick with someone, they could just keep initiating a new password reset. Then the poor target has to logon and change the password again and again.
By sending a token, the user's password does not change until they login with it and confirm it. The spam of reset emails can be ignored. Tokens are just as easy (if not easier) to generate as a new password by using a GUID, it's not really extra hassle for the developer.
Also, because the GUID is unique (a generated password might not be), a token can be tied to a username. If the incorrect username is given on the URL, then the token can be cancelled (i.e. when a different person initiates it and someone intercepts it.. assuming that the username isn't the same as the email).
#Jay. The proper use of security questions is to initiate a password reset email, not for actually resetting the password. Without a mechanism such as a security question, one could initiate a password reset. Althought seemingly beign, sending a reset email could be sent to an email that might no longer belong to the original owner. This is not rare. For example, when employees leave a company, often those mails are forwarded to another employee. A security question, adds a low level of obfucation to that scenario. It also reduces issues where one person keeps initiating a password reset on the wrong account causing some poor sod to get unintentionally spammed. Security question are really not meant to be truely secure, they are just meant to reduce scenarios such as those. Anyone using a security question to actually reset the password is doing it wrong.
Regarding security question/answer. As a user of websites I personally don't use them (I enter garbage in them). But they are certainly not useless or meaningless as some say here.
Consider this situation:
A user of your site has left his desk to go to lunch and didn't lock his workstation. A nefarious user can now visit the page for recovering/resetting password and enter the user's username. The system will then email the recovered/reset password without prompting for the security answer.
Here's an example of how someone did it with Node.js, basically generate a random token, an expiry time, send out the link with the token attached, have a reset/:token route that ensures a user exists with that token (which is also not expired) and, if so, redirect to a reset password page.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
I'm wondering what the best method is for creating a forgot password function on a website. I have seen quite a few out there, here are a few or combination of:
passphrase question / answer (1 or more)
send email with new password
on screen give new password
confirmation through email: must click link to get new password
page requiring user to enter a new password
What combination or additional steps would you add to a forgot password function? I'm wondering about how they request the new password and how they end up getting it.
I'm operating on the principal that the password cannot be retrieved; a new password must be given/generated.
Edit I like what Cory said about not displaying if the username exists, but I'm wondering what to display instead. I'm thinking half the problem is that the user forgot which email address they used, which displaying some sort of "does not exist" message is useful. Any solutions?
I personally would send an email with a link to a short term page that lets them set a new password. Make the page name some kind of UID.
If that does not appeal to you, then sending them a new password and forcing them to change it on first access would do as well.
Option 1 is far easier.
A few important security concerns:
A passphrase question / answer actually lowers security since it typically becomes the weakest link in the process. It's often easier to guess someone's answer than it is a password - particularly if questions aren't carefully chosen.
Assuming emails operate as the username in your system (which is generally recommended for a variety of reasons), the response to a password reset request shouldn't indicate whether a valid account was found. It should simply state that a password request email has been sent to the address provided. Why? A response indicating that an email does/doesn't exist allows a hacker to harvest a list of user accounts by submitting multiple password requests (typically via an HTTP proxy like burp suite) and noting whether the email is found. To protect from login harvesting you must assure no login/auth related functions provide any indication of when a valid user's email has been entered on a login/pass reset form.
For more background, checkout the Web Application Hackers Handbook. It's an excellent read on creating secure authentication models.
EDIT: Regarding the question in your edit - I'd suggest:
"A password request email has been
sent to the address you provided. If
an email doesn't arrive shortly,
please check your spam folder. If no
email arrives, then no account exists
with the email you provided."
There's a trade-off being made here between ease of use and security. You have to balance this based on context - is security important enough to you and your users to justify this inconvenience?
Send email with new password.
FORCE a password change when they arrive and key in the new password.
This ensures that the person who wanted the password will be the only only getting in to the account.
If the email is sniffed, someone could get in to the account (of course), but the real party will discover this immediately (as their password you just sent them doesn't work).
Also send confirmations of password changes to the users.
If someone get the new password, and then an email saying "thanx for changing the password", they're going to be rather puzzled and will talk to an admin if they didn't do it.
Using the email verification/password reset link will give you better security.
If you look around this is how most websites do it and people are pretty used to this verification, so I'd recommend using this type of authentication.
I would think (gbrandt's) Option 2 would be a great method if it is combined with some personal information you already have for the user. i.e date of birth.
When the user requests a new password (reset) via entering his email address, he also has to enter a correct date of birth (or something else) before the password is reset and a new one is emailed to the user.
Only those who know him well can possibly annoy him by resetting his password! It cant be a stranger or a bot
Upon 5 or 7 bad email-address & date of birth combinations the user is emailed that his password has been requested to be reset and has failed due to an incorrect credential. Then password resetting for that account is suspended for 24hrs or any desired period.
(if too many users contact the webadmin regarding this email he'll know someone is trying to maliciously attain information from your website/app)
What do you guys think?
Option 1. is not a good idea, as generally his becomes easily guessable by others. Sarah Palin's personal email (Yahoo I think) was hacked in this way by a third party.
The other options are better and previous posts have outlined the detail.
The idea I was thinking about was to sign the data in the link that is sent to the user. Then, when the user clicks the link and the server receives the call, the server also gets the encrypted part and can validate that the data was untouched.
I have implemented a JAVA project for this use case. It is on GitHub, open source. It answers your question perfectly... implemented in Java.
As for the link in the email - it generates the link, plus validates it upon usage.
There are explanation for everything (and if something is missing - let me know...)
Have a look: https://github.com/OhadR/Authentication-Flows
See a Demo here.
This is the client web-app that uses the auth-flows, with the README with all explanations. it directs you the implementation: https://github.com/OhadR/authentication-flows/tree/master/authentication-flows