Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Recently someone of my friends tells me that he logged in my facebook account without knowing my password and without login alerts warning, he told me that he hacked my facebook account with some techniques. so my question: Is it possible to login into facebook account which facebook account owner allows unexpected logs alerts without him knowing that?
Technically, yes
It is pretty close to impossible for him to have accessed your Facebook account without knowing your password via his own devices such as "hacking" your account. If anyone were to log into your account they would need your email and password, and this would often send you a code to your phone (2-factor authentication) or require you verify that it is definitely you logging in via an already-authorised device.
However, if he has gained physical access to one of your devices such as your phone, laptop or desktop PC where you are already logged in, he may be able to access your account from there. Because you're already logged in, he doesn't need the password. And because you've already verified it was you who logged in (because it was your device) then Facebook still thinks it is you logging in.
My advice
I would strongly advise you password protect each of your devices (your PC, phone, laptop, work or school account etc.) with a long yet memorable password or pin code. Don't pick anything that can easily be guessed such as "password" or "1234". Here's a relevant XKCD.
Each time you leave your computer or stop using your phone, lock it!
To be extra sure
If you'd like that extra piece of mind that he isn't in your account, here's an extra couple of steps you can take.
First thing is first - link up your mobile phone to your account as a 2-factor authenticator. Whenever you log into your account from a new device, it will ask you to verify that device via a text message sent to your phone. This works per application too, meaning if you log into facebook on your phone via Chrome browser, it will be a different login to the Facebook app - so you'll need to verify twice!
Secondly, change your password if you think this person may know it. If there's even the slightest chance he might have your password or that it is easy to guess, change it immediately! The longer the better.
Next, you'll want to add email verification tokens using a PGP key. This encrypts your emails so that even if someone gains access to your account, they can't change the email and own it since they need to decrypt it with your key (you can Google this for more details on how to set it up). Also another relevant article on setting this up. Make sure this is working properly before you move to the next step!
Finally, go into your Facebook settings and under your Active Sessions, click the "Log out everywhere" button. You will need to log into each device again and then hopefully use your phone to authenticate each login. This way you should pretty much guarantee that if you did accidently log into your account somewhere, it will be signed out next time this person tries to access it.
Ensuring it doesn't get accessed again
Finally, don't let your friends get access to your devices, and don't let them know your passwords. To prevent people from stealing your password, don't go clicking on any suspicious links or downloading any crapware.
I hope this helps
first of all, I don't really know if this is the right place to ask this, if this should be moved, please do so or let me know.
I'm building a mobile app (using phonegap) which is kind of a banking app, hence, I need a really secure method for resetting a lost/forgotten password.
I do not want to use email links or sms codes to proceed to the resetting part because:
Email address can be already compromised.
(Where I live) Phone can be stolen (most likely) and the email could be linked to phone, so SMS would be pointless as well.
So after a bit of reading I have come up with the next idea, inside the app when user clicks forgotten password:
Ask user email of registration.
Ask which country, state and city were selected when registration occured.
Ask if the user had login successfully in the last 3 or 7 days (maybe less is better?).
Ask the last amount of money received (if any).
Ask the last amount of money sended (if any).
Ask the date of the last transaction known (sended or received before or during the last successfull login).
If all that information proves to be correct, let the user set a new password. Else just show a message telling the user that something in the information was wrong, never ever specifing what was wrong.
Those are a few question but I'm writing this as it just occurs to me. There will be more question based on the user expirience using the app.
My Questions:
Is this secure?
Which are the weaknesses of this idea?
Does this effectively replace the email/link combination or phone/sms?
Thanks in advance.
Updates:
I dont like setting security questions during registration because most people forget the answer or type carelessly and then they are trapped with a forgotten account.
I will not be using any bank account or credit/debit card information.
All operations will be in effect inmmediatly.
Maybe I should use questions only related to the use of the app?
This method is relatively secure as password recovery goes. However, it is not very user friendly, and it is very likely that the user can get locked out. On the other hand, a thief may easily still recover a password. Taking all the questions one by one:
Ask user email of registration.
An thief who has stolen a phone has access to this (most likely).
Ask which country, state and city were selected when registration occurred.
This will also be easy to retrieve if the thief searches in the emails of the user. Even if no such info is displayed there, knowing the name of the user, the thief can look in whitepages websites or Facebook and get valuable info.
Ask if the user had login successfully in the last 3 or 7 days (maybe less is better?).
A lucky guess with 50% chance can get the thief past this. A legitimate user might also not remember, which causes the first usability problem of this method.
Ask the last amount of money received (if any).
This is very hard to remember, especially if this does not happen a lot, or happens all the time and the amounts vary. A thief who knows the bank account of the user (maybe info like the IBAN is in the emails) can also transfer a small amount to that account and get past this stage.
Ask the last amount of money sent (if any).
If this involves transactions as well (paying using a credit card), a thief can follow a legitimate user and observe the money spent in the last transaction. If not, it is still a big usability issue, as the user is not likely to remember. The thief can also check the emails of the user and see if there were any goods bought online (Amazon for example sends a confirmation email) and input this as the amount.
Ask the date of the last transaction known (sent or received before or during the last successful login).
Again, this is very hard to remember for the legitimate user. Especially when it comes to receiving money, it can take days, so even if the user knows that a payment to him/her was due at day X, there might have been a delay of a few days.
If I were you, I would put email, username, last password that the user remembers, and 2-5 recovery questions that the user has to set up in the beginning. I would let the user try a total of 3 times, and all these events are logged and the bank notified. Otherwise, the user has to contact the bank in order to change it. Calls are recorded, and personal info is requested, along with a phone banking password. If the user fails again, he/she has to go to the bank with some form of photographic ID.
Response to updates: If an app is not being used on a daily basis (banking-like apps are the case for many users), it might not be a good idea to ask questions regarding the use of the app.
Regarding security questions, maybe if you set a message that warns the user that they might get locked out of their account if they forget them, might convince them to be more careful. Maybe you can let users choose both questions and answers (just make sure the questions and answers are different each time, and they are longer than 1-2 characters).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've notoced lots of websites allow users to register by simply asking their email and password [aside all the other information like name, username, genre etc.]. And the users don't have to do email verification as they register, they simply have a reminder that they should verify their email, but otherwise they can use the website normally. This is very good for UX, since the user can immediately start using a website and not wasting time to do email verifications etc. before he knows whether he will keep using this website or not.
So the question I wanted to ask is the following:
Suppose a malicious user writes a program that will keep registering users with valid usernames and valid(syntactically) emails.
This will eventually cause lost of trouble if not correctly managed:
the database will eventually run out of ids for users
This will create lots of records, thus eating up space
More user records, means more lookup time
So, I'm really curious how all this is managed, if at all.
NOTE: most of websites I'm talking about, do not use CAPTCHA(bad for UX), so they manage the issue in some other way, again, if at all.but neither the solution is to delete the record if the user hasn't confirmed his/her email in a time term. For suppose user looses Internet connection[, or forgets, or anything else] the last day he has to verify email. So the user will loose his/her account and just forget about that website. So this is not a solution. not sure about IP limitations. But suppose that is an Internet cafe and users keep registering. And there are dynamic IPs these days. Is limiting the registration to some amount of time a solution? But how do I know when the last registration occurred if the IP keeps changing. So how is this issue solved?
This is not really an SO problem. This site is more focused on solving issues with actual code rather than ways to solve a generalise problem.
That said, the current patterns seem to be...
Require more information. By having more information, you can de duplicate accounts. That said, in your scenario repeated accounts with the same email address should be easily consolidated. This doesn't prevent bots from registering many accounts with different addresses, but adding more requirements, such as address and phone number make it increasingly differcult to match data sets to your validation.
Validate via email. Contrary to what you suggest, this is still quite common and a good means to weed out genuine users with interest in the site from the chaff.
The other option is a federated authentication service such as Facebook, Twitter, Google+. These provide the UX you seek, but without it being your problem to validate.
From your comments that these changes aren't an option...
Your other option is to look at something server side. This will be along the lines of blocking by IP address. The problem I'd have with this is that the user is unaware, at least with the other options presented the user isn't going to get denied based upon something that happens backend. These measures can still be easily circumvented. An IP block can only be implemented for a short period of time, so the rogue registrations just need to delay long enough or more likely flip between different IP addresses.
Been reading up on MitB attacks and some things worry me about this.
From WIKI:
The use of strong authentication tools simply creates an increased level of misplaced confidence on the part of both customer and bank that the transaction is secure.
One of the most effective methods in combating a MitB attack is through an Out-of-Band (OOB) Transaction verification process. This overcomes the MitB Trojan by verifying the transaction details, as received by the host (bank), to the user (customer) over a channel other than the browser
So if I get this straight, that the only real safe method is a non browser confirmation method. (like a phone call or some other external tool)
Would an email count as a OOB Transaction? Or could the MitB send a fake email?
Is there a way to prevent MitB with only code?
EDIT: I'm asking this because our local banking system are employing a physical keygen system for which you have to push to get a number and then enter that number into a field in the transaction form.
I have no idea if that is considered safe, since it looks like a MitB attack is just making it look like everything you did is safe and correct but what actually happened is that the form data was changed on submit and is now transferring to some other bank account. So it would have access to this keygen number.
Would an email count as a OOB Transaction?
Given the prevalence of Web mail services like GMail, I would say No. Even if the target of such an attack isn't using Web mail, an attacker that has control of the target's browser could fire off a fake email, just as you suggest.
Generally speaking if your machine is infected then you are vulnerable no matter what.
A physical token or "out of band" token is designed to solve the "identity" problem and gives the bank higher confidence that the person logging in is the person they say they are. These sort of mechanism normally involve using a "one time code" technique so that even if someone is recording the conversation with the bank, the token can't be reused. However if the malware is intercepting in real-time then they can maliciously control the account after you have successfully logged in, but often banks require a new 'code' each time you try and do something like transfer money out of the account. So the malware would have to wait for you to do this legitimately and then modify the request. However most malware are not real-time and send data to a 3rd party for collection and later use. Using these "one time token" techniques would successfully defend against this post processing of the login data, because the recorded data can't be used later to login in.
To answer your question, there is no way to defend against this only in code. Anything you do could be specifically worked around in a piece of malware.
In the article which is the subject of (and referenced by) that Wikipedia article, step 1 in the "Method of Attack" is stated as:
The trojan infects the computer's software, either OS or Application.
The answer to your question is therefore "no": once the O/S is infected then the malware can (theoretically at least) be intercepting your email too.
As an aside, some client platforms (e.g. even mobile phones, not to mention dedicated point of sale terminals) are less susceptible to infection than others.
I suppose you could use critical pieces of the transaction information as part of a secondary or tertiary transaction verification step. That is, if I thought I told the bank account #12345 and it heard #54321 because the data was adulterated by that type of attack, the secondary verification would fail the encryption check. It would also be possible for the bank to echo back something that was more difficult to alter, like an image containing the relevant information.
The thing about these types of discussions is that it can always get more complicated. Email is not valid out of band step because, I have to imagine I have a rootkit ... if I stop that, I have to imagine that my OS is actually a guest OS running in an evil virtual machine ... if I stop that, I guess I have to imagine it's the matrix and I can't trust anything all to protect my visa card with $200 of available credit. :)
This is my point of view for the man in the browser. The man in the browser is as if:
The victim stands up, leaves his computer, and move his back to his computer, so he can not touch the keyboard, move the mouse or even see the screen.
A hacker sits behind victim computer.
If victim wants to work with his computer he must ask the hacker to do it for him. If he wants to see any result, he must ask the hacker to read the data on the monitor.
The hacker does his best to convince the user that he is doing what he asks for and repeats what he seas. But try to make the benefit of this situation with no mercy !
As a simple case:
Victim may ask hacker to fill a transaction form data as transfer 500USD to mom.
The hacker instead can type transfer 10000USD to Jack. ( Tamper form data before send)
The system may display, I have transferred 10000USD to Jack but the hacker says that the 500USD has transferred to Jack. ( Tamper result HTML)
The victim asks to see his account balance, to make sure that the transfer is done.
The hacker can say that the the account balance in correct ( This can be done for example, by removing the last line of balance table and changing the balance amount in HTML)
As for email:
You are waiting for an email, and ask hacker do I have a confirm email from bank.
As you can not see the monitor, he say yes you have. (Technically he can generate a fake email easily).
(even if you sit on another clean computer, a fake email can be sent to you again)
The image generation can not prevent attack.
You ask the hacker, my bank should shows me an image which must display the transfer information, could you see it, what does it says.
The hacker reply: Yes I can see it, it says "You are transferring 500USD to mom" (The image can easily created by the JavaScript or hacker can point the image url to a server, which generates a dynamic image with appropriate data to cheat user)
The very dangerous situation may happens as the man in the browser change the flow of the site. In this case even an OTP or kegen system can not prevent the attack. For example:
You ask hacker that you want to see your balance
The hacker goes to transfer account page, and fill a transfer account form to transfer 10000USD to jack ( but you don't know what is he doing at all, you are just waiting) he come to a page that asks him for a key. This is the key you which you must give him.
Now, the hacker says : Well, the bank ask me if you want to see your balance you must enter a key.
You think, well a key for balance seems strange, but any way lets give that key, I trust this guy !!
The hacker switch back to transfer form and use the key to do the transfer.
So as you can see there is no server side solution for a Man in the browser you can:
Use a out of the band solution to inform critical information to user. ( This is as if you take a mobile in your hand and although your back is still to your computer but sensitive information are sent to your TRUSTED device and you can see critical information)
Use a hardened browser to make sure that no one can change its behavior. ( Sit back to your computer :) )
Good samples of what can be done by MITB can be found at: http://www.tidos-group.com/blog/2010/12/09/man-in-the-browser-the-power-of-javascript-at-the-example-of-carberp/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
From Wired magazine:
...the Palin hack didn't require any
real skill. Instead, the hacker simply
reset Palin's password using her
birthdate, ZIP code and information
about where she met her spouse -- the
security question on her Yahoo
account, which was answered (Wasilla
High) by a simple Google search.
We cannot trust such security questions to reset forgotten passwords.
How do you design a better system?
The insecurity of so-called "security questions" has been known for a long time. As Bruce Schneier puts it:
The result is the normal security protocol (passwords) falls back to a much less secure protocol (secret questions). And the security of the entire system suffers.
What can one do? My usual technique is to type a completely random answer -- I madly slap at my keyboard for a few seconds -- and then forget about it. This ensures that some attacker can't bypass my password and try to guess the answer to my secret question, but is pretty unpleasant if I forget my password. The one time this happened to me, I had to call the company to get my password and question reset. (Honestly, I don't remember how I authenticated myself to the customer service rep at the other end of the phone line.)
I think the better technique is to just send an e-mail with a link they can use to generate a new random password to the e-mail account the user originally used to register. If they didn't request a new password, they can just ignore it and keep using their old one. As others have pointed out, this wouldn't necessarily have helped Yahoo, since they were running an e-mail service, but for most other services e-mail is a decent authentication measure (in effect, you foist the authentication problem off on the user's e-mail provider).
Of course, you could just use OpenID.
Out-of-band communication is the way to go.
For instance, sending a temporary password in SMS may be acceptable (depending on the system). I've seen this implemented often by telecoms, where SMS is cheap/free/part of business, and the user's cellphone number is pre-registered...
Banks often require a phone call to/from a specific number, but I personally am not too crazy about that....
And of course, depending on the system, forcing the user to come in to the branch office to personally identify themselves can also work (just royally annoy the user).
Bottom line, DON'T create a weaker channel to bypass the strong password requirements.
Having seen a lot of posters suggest email, all I can suggest is DONT use email as your line of defense.
Compromising somebodys email account can be relatively easy. Many web based email services DONT provide any real security either, and even if they offer SSL, its often not default and you are still relying on the weakness of the email password to protect the user ( Which, in turn has a reset mechanism most the time ).
Email is one of the most insecure technologies, and there are good reasons why its a really bad idea to send information like credit card details over them. They're usually transmitted between servers in plaintext, and equally often, between server and desktop client equally unencrypted, and all it takes is a wire sniff to get the reset url and trigger it. ( Don't say I'm paranoid, because banks use SSL encryption for a good reason. How can you trust the 20-200 physical devices on the route have good intentions? )
Once you get the reset data, you can reset the password, and then change your(their) email address, and have permanent control of their account ( it happens all the time ).
And if they get your email account, all they have to do is have a browse through your inbox to find whom you're subscribed with, and then easily reset the password ON ALL OF THEM
So now, using the email based security, can lead to a propogative security weakness!. I'm sure thats beneficial!.
The question being asked Is one I figure is almost impossible to do with software alone. This is why we have 2-factor authentication with hardware dongles that respond to challenges with their own unique private key signature, and only if you lose that are you screwed, and you then have to deal with a human ( oh no ) to get a new one.
It 'depends' on the 'system'.
If you are a Bank or a credit card provider, you have already issued
some physical token to your customer that you can validate against and more.
If you are an ecommerce site, you ask for some recent transactions
-exact amounts, credit card number used et al..
If you are like Yahoo, an automated approach I would use is to send an
activation code via either a phone call or a text message to the cell
phone along with some other basic question and answers.
Jay
Do away with the (in)security questions completely. They're such an obvious security hole that I'm actually a bit surprised that it's taken this long for them to create a serious (well, highly-publicized) incident.
Until they disappear, I'm just going to keep on telling websites which use them that I went to "n4weu6vyeli4u5t" high school...
Have the user enter 3 questions and answers. When they request a reset present them with a drop down of 5 questions, one if which is a random one from the 3 they entered. Then send a confirmation email to actually reset the password.
Of course, nothing is going to be truly "hacker proof".
When users are involved (and mostly when not, too) there is no security; there is only the illusion of security. There's not a lot you can do about it. You could have 'less common' security questions but even they are prone to exploitation since some people put everything out in the public eye.
Secondary channels like email offer a reasonable solution to the problem. If the user requests a password reset you can email them a password reset token. Still not perfect, as others have said, but exploiting this would require the attacker to be somewhere in the line of sight between the website, its MTA and the users MUA. It's technically easy but I suggest that the reality is it's just too much work/risk for them to bother on anyone except very high profile individuals.
Requiring the user to supply SSL or GPG public keys at account creation time will help enormously, but clueless users won't know what those things are let-alone be able to keep their private keys secure and backed up so they don't lose them.
Asking the user to supply a second emergency password (kind of like PIN/PUK on mobile phone SIM cards) could help but it's likely the user would use the same password twice or forget the second password too.
Short answer, you're S.O.L unless you want to educate your users on security and then hit them with a cluestick until they realise that it is necessary to be secure and the slight amount of extra work is not simply there to be a pain in the arse.
Authenticating everything by sending emails is a reasonably effective solution. (although, that might not have been workable for Yahoo in this case :)).
Rather than messing about with security questions or other means to recover passwords, simply respond to password recover requests by sending an email to a predefined email account with an authorisation link. From there you can change passwords, or whatever you need to do (never SEND the password though - you should always store it as a salted hash anyway, always change it. Then if the email account has ben compromised, at least there's some indication to the user that their other services have been accessed)
The true answer is, there isn't a fool proof way to keep hackers out. I hate security questions, but if your going to use them, allow for user defined security questions. As a user, if I must have a security question on a site to set up an account, I really like having the ability to setup my own security question to allow me to ask something that only I know how to answer. It doesn't even have to be a real question in this case. But a users account is then as secure as the stupidity of the user, and the fact that many users will use something like "question?" and "answer!" or something equally dumb. You can't save users from their own stupidity.
Treating these security questions as something actually being two-factor authentication is totally misleading. From spurious items read before, when certain (banks) sites were required to have "two-factor authentication" they started implementing this as a cheap way to do it. Bruce Schneier talked about this a [while back][1].
Multiple factors are best things that are not-the-same. It should not be all things you "know" but something you know and something you have, etc. This is where the hardware authentication tokens, smart cards, and other such devices come into play.
[1]: http://www.schneier.com/blog/archives/2005/03/the_failure_of.html The Failure of Two-Factor Authentication
when its not an email system, email them a link to a secure page, with a hash that must come back in the query string to reset password.
Then if someone tried to reset your password, you would know, and they wouldn't be able to guess the hash potentially.
We use 2 guids multiplied together, represented as hex.
Well for one it should not directly reset the password but send an email with a link to reset the password. That way she would have got the email and known that it was not her who initiated the reset, and that her question / answer had been compromised.
In the case where the email address is no longer valid, it should wait for a timeout ( few days or a week ) before allowing a new email to be attached to an account.
Send a message to a different e-mail account, or text their cell phone, or call them, or send a snail-mail message. Anything that doesn't involve matters of public record or preferences that may change at any time.
Good security questions are a misnomer. They actually create a vulnerability into a system. We should call them in-secure questions. However, recognizing the risk and value they provide, "good" security questions should have 4 characteristics:
1. cannot be easily guessed or researched (safe),
2. doesn't change over time (stable),
3. is memorable,
4. is definitive or simple.
You can read more about this at http://www.goodsecurityquestions.com.
Here's a list of good, fair, and poor security questions.
IMO Secret questions should only be used as a very weak control with a time limit as part of a system.
Ex: Password reset system.
You are authenticated. Registrate your mobile phone number and your secret(not so secret) answer.
You forget your password.
You request to unlock it.
a) Your "Not so secret" question asks you for the "not so secret answer".
b) If correct, a text message is sent to the pre registrated phone.
This way, if your phone gets stolen and also, controls like pin/lock on the phone is not working. You still will have a measure of obfuscation for the attacker to get to reset the password until the time it is reported the phone is lost/stolen and can be disabled.
This usage is what i think the only purpose at all for the "not so secret" questions/answers.
So i would argue there is a place in this world for them and that usually a system needs to be the discussion.
Only provide questions that aren't on the public record.
always send the password reset to a registered email account (which is tricky for an email account) or send a PIN number to a registerd mobile phone, or a link to a IM address, etc - basically, capture some secondary contact information on registration and use it to send a 'password reset' link.
Never let anyone change their password directly, always make sure they go through an additional step.
I prefer to keep things simple and use an honor system approach. For example I'll present the user with something like,
Is this really you? Select: Yes or No.
How about requesting the users to enter their own security question and answer, and a secondary email (not the one where the password reset link is sent). Store the security question and answer hashed in the database for that extra step of security.
If the user forgets his/her password, send the password reset link to the user's primary email.
User then clicks on the link which redirects and asks for the security question and answer. If this step is successful then allow the user to reset his/her password. If the user forgets the security question/answer send a link to reset the security question/answer to the user's secondary email.
If the attacker gets access to one of the emails, it will still be useless without access to the other (very unlikely the attacker can get access to both). I know this process needs a lot of extra work on both the developers and users, but I think it is worth it. (Maybe we could give the users a recommended option to activate the security question/answer if they need this extra bit of security.)
Bottom line is that how strong or weak this system works will depends heavily on the user. The strength of the security question/answer and how well the two emails are "untied" (that is, there is no way of gaining access to one email through the other) will decide this systems strength.
I don't know if there are any problems with this way of doing it, but if any, I'd be happy if anyone could point those out :)
Generate a hash that contains the person's username and password and send it over Https to the user as a file. The user saves the file to disk. It is their responsibility to store this file in a secure location. Alternatively you can send it to their email address but this will result in less security. If the user forgets their login credentials they must then upload this file. Once the server verifies the username and password, they are then presented with a dialog to alter their password.
Due to the evolution of social media, security questions asked by websites are too easy to crack. Since most of the questions are personal information which is easily available on social media platforms one or another. One of the alternatives to avoid account hacking is to make password rules strict for login like adding special characters, numerical, capital letters etc. These kind of passwords are hard to decode and can enhance the security to a great extent.
But there are new alternative methods like multi-factor authentication, passwordless login, SMS authentication etc. SMS authentication is part of multi-factor authentication where a user is provided with an OTP on his/her cellphone which he/she need to enter in order to log in to a website. This is a secure way since the access of mobile is limited to the user only(mostly). Another multi-factor authentication method is sending a verification link to email to complete the signing in process. There is a very well written blog on this topic on Medium that explains this concept in a detailed manner.