{"id":27194,"date":"2015-09-29T12:18:18","date_gmt":"2015-09-29T06:48:18","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=27194"},"modified":"2022-01-11T12:10:03","modified_gmt":"2022-01-11T06:40:03","slug":"abusing-password-reset-part-2","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/abusing-password-reset-part-2\/","title":{"rendered":"Abusing Password reset functionality to steal user data (Part\u20132)"},"content":{"rendered":"<p>In continuation to my last <a title=\"blog\" href=\"http:\/\/www.tothenew.com\/blog\/abusing-password-reset-part-1\/\">blog<\/a>\u00a0about possible attacks on a password reset functionality, this part of the same series will look into below two implementations:<\/p>\n<p style=\"padding-left: 30px;\">\u2022 Email sent with a temporary password or current password<br \/>\n\u2022 Secret questions asked and then given the option to reset the password<\/p>\n<p>I will mention possible issues which might occur with each of these implementations and how an attacker can make use of such vulnerability to hack an account. So, let\u2019s start with the first:<\/p>\n<h3>Email sent with a temporary password or current password:<\/h3>\n<p>You must have seen various applications over the internet which uses this type of password reset. The process is:<\/p>\n<p style=\"padding-left: 30px;\">\u2022 User clicks on the button of \u201cForgot Password\u201d or a similar button and is sent to a page where he needs to select the account or provide the associated email address.<br \/>\n\u2022 Once the user provides the email address or username, the application checks if the account is valid or not.<br \/>\n\u2022 Finally, the application sends the password in clear text over an email to the user.<\/p>\n<p>In this whole process, the core idea is that the application relies on the security of the email system and this is the catch. What if:<\/p>\n<p style=\"padding-left: 30px;\">\u2022 The user\u2019s email has got hacked and now the attacker is trying to get access to his\/her bank account.<br \/>\n\u2022 The email which the user uses does not provide proper security and is vulnerable to hacks.<br \/>\n\u2022 The email account is accessed over HTTP, and hence the traffic between the email account and the user\u2019s browser is vulnerable to Man In The Middle Attack.<\/p>\n<p>Considering the above cases, it is not the best advisable method for implementing the password reset functionality. Let\u2019s take an example and see the possibilities:<\/p>\n<p>John is a regular user of an e-commerce website (www.bad-ecom.com) and loves to shop. Unfortunately, long back when he registered on the website he used a poor email\u00a0service provider. But due to long usage, he is not willing to create a new account as all his older orders are there with the old account only.<\/p>\n<p>Paul lives next door and is always hunting for opportunities to hack John. One day, Paul was able to guess the password of John\u2019s WiFi network and started to sniff all the traffic. But unfortunately, everything was encrypted, all the major websites that John access are over HTTPS. To his surprise, there was one website which was working on HTTP and this was the bad email provider for John. Now, Paul got access to John\u2019s email account but could not find anything in the email, apart from emails of www.bad-ecom.com.<\/p>\n<p>So he then decided to reset the password of bad-ecom application and was able to get access to John\u2019s account on bad-ecom as he got the clear text password over the hacked email. The logical issue is that the bad-ecom application is relying on the email to be secure enough. It might come to your mind that if the email gets hacked then all the methods of password reset can be hacked, but I will explain the best method of implementing this in my next part of the blog.<\/p>\n<p>Also, there are cases in which this implementation may have improper settings like;<\/p>\n<p style=\"padding-left: 30px;\">\u2022 Temporary password never expires<br \/>\n\u2022 Temporary password is easy to guess<br \/>\n\u2022 There is no rate limit applied for temporary password generation.<\/p>\n<p>Considering all the above cases, it is never the best way to implement for password reset functionality. Similarly, let&#8217;s analyze the implementations with secret questions.<\/p>\n<hr \/>\n<h3>Password Reset with secret questions:<\/h3>\n<p>Before going ahead, just think for once that how many times we actually try to choose the most difficult question and provide a \u2018difficult to guess\u2019 answer\u2026\u2026 Never\u2026 right?<br \/>\nSo for a critical application, relying on this type of implementation is itself very vulnerable because of human nature.<\/p>\n<p>But there can also be other ways of hacking a secret question-based system. For example, some time ago a Facebook vulnerability was disclosed. In this, after answering the secret question wrongly for 3 times, the user gets an option to choose one of the friends from his\/her friend list to recover the password. So, it was possible for an attacker to add himself to the victim\u2019s account and then choose himself while resetting the password of victim.<\/p>\n<p>Hence, it is very crucial for secret questions to have difficult answers and limit the number of wrong attempts. If you have selected your dog\u2019s name as the secret question, then that\u2019s not very secret.<\/p>\n<p>Take a look at Secret Questions for a popular\u00a0website.<\/p>\n<p><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-27202\" src=\"\/blog\/wp-ttn-blog\/uploads\/2015\/09\/screen_shot_2012-08-13_at_10.56.51_am3.png\" alt=\"screen_shot_2012-08-13_at_10.56.51_am3\" width=\"526\" height=\"236\" \/><\/p>\n<p>Most of the above mentioned questioned does not have a very secret answer. Hence, there is a possibility that the victim might unknowingly leak details about these things. For example, how many times do you ask the person over a call (from a bank) to validate and prove his identity before you answer his questions&#8230;. very rarely or probably never. So, an attacker can make a fake call to you and get this information easily from you only.<\/p>\n<p>Any application which deals with critical data, secret questions should be one of the details required to reset the password, but should not be the only detail required.<\/p>\n<p>Some suggestions to developers:<\/p>\n<p style=\"padding-left: 30px;\">\u2022 Do not only rely on users to chose the difficult questions, rather implement something which restricts them to have &#8216;difficult to guess&#8217; answers.<br \/>\n\u2022 Provide an option to choose personal questions.<br \/>\n\u2022 Never directly give the option to go to the secret questions; this will give the attacker a hint about what to social engineer for i.e. never show all the secret questions on the same screen. Always go to next question if the user answers the previous one correctly.<\/p>\n<p>Secret questions are being used in numerous websites as a mechanism to reset the password. But it may have vulnerabilities if not implemented properly.<\/p>\n<p style=\"text-align: left;\">Thus, it is important to assess the level of security of your application at regular intervals. This is as simple as answering a 5-minute questionnaire like the one below &#8211;<\/p>\n<p>Follow the next and final part of this series to know about the best possible way to implement a password reset functionality.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In continuation to my last blog\u00a0about possible attacks on a password reset functionality, this part of the same series will look into below two implementations: \u2022 Email sent with a temporary password or current password \u2022 Secret questions asked and then given the option to reset the password I will mention possible issues which might [&hellip;]<\/p>\n","protected":false},"author":234,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":5},"categories":[2026],"tags":[2274,2270,2271,227,2268],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/27194"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/234"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=27194"}],"version-history":[{"count":1,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/27194\/revisions"}],"predecessor-version":[{"id":54523,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/27194\/revisions\/54523"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=27194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=27194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=27194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}