me too, although some sites now require something more secure than my default password (more length, and complicate combinations of Caps, Lower case, Numbers and punctuation) which is a pain as .I now have several default passwords!!
If you do a "lost password" email request, and get your password back so you can just login, then the site is very insecure. It means that the password is being stored in plain-text (in a database or whatever) so anyone successfully hacking that site will get your password and email address. Make very sure that you don't use that password anywhere else which has personal data / financial data etc., and if it is a site that has personal / financial data then avoid!
(The software way around this is to use "Salt & Hash"; it takes your password, when you register, and encrypts it with a one-way cipher (no formula exists for reversing it). In addition add some random information (e.g. your User Record number) so that someone else with the same password doesn't generate the same encrypted password. Store that encrypted password in the database.
When you login re-encrypt the password you typed with the same formula, and compare that against what is stored in the database.
If you forget your password then send an email issuing you with a one-time password, valid only for a short time, and require you to change your password after login - then you'll be able to put something more memorable in)
I've forgotten the details, but companies that store card details get reduced fraud compensation from the card company. Companies should not store you CVV off the back of the card, so you should need that each time you make a purchase, or the company will process the payment without using that (at increased risk to themselves if your transaction is duff) plus you are also likely to have to do 3D-Secure authentication - you have a password for your credit card, additional to the information stored on the card itself. The company sends the transaction details to your bank and then you have a conversation with your bank (direct) to exchange your 3D secure password - it may look like its the Vendor's website but actually its direct with your bank, so the Vendor never stores that data, even momentarily in its cache memory etc., so in theory should be harder to hack / breach - other than by Phishing attacks I suppose)
If you don't have a 3D-Secure password set up on your cards it would be a good idea to do so. I have a separate card that I only use online - that way if it is hacked / compromised my normal card doesn't get stopped too.
||Salt & Hash is breakable and if done with a SHA1 hash is very easy with the right tools. When you can compute 30 billion SHA1 hashes per second with consumer hardware, cracking even salted hashes is a cinch.|
I use a password manager, Lastpass. It creates complex passwords I have both a long human phrase based password for it and two factor authentication switched on so any new device needs a code from my phone as well as my master password
It can get a little annoying on my phone as as i have to go into the app to get the password but on the computer there is a chrome plugin which auto fills things for me
There are something I keep suitable passwords I can type from memory for as the last pass system isn't suitable. This is iTunes and my bank
It works for everything else though
|Dev: Iím going to build a website where people can register, get a nice welcome email then log in and do a bunch of stuff under their identity.
Me: Cool, will you let people register multiple times with the same email address?
Dev: No way! Thatíd cause all sorts of problems, Iíll tell them if they already have an account on the system.
Me: But does that mean an attacker can simply enumerate through a list of email addresses and see which ones exist in your system.
Dev: Uh, kindaÖ does it really matter though?
Me: It can matter, it depends if thereís a reasonable expectation of privacy on behalf of the account holder. We can sort that out by verifying the identity via the welcome email you were going to send them anyway. Have you planned any anti-automation defences on the registration form?
Dev: Why would we bother, itís just registration?
Me: What if someone auto-registers a million random people using a freely available email list and they all get a welcome email they didnít expect?
Dev: Why on earth would anyone do that?! Whatís the upside for them? And whatís the damage to the system?
Me: Well thereís reputation damage for a start, then thereís the damage it does to your spam rating when people start flagging the emails as spam and jeopardising your ability to deliver the legitimate ones. Attackers donít always need a reason, itís often just ďlulzĒ.
Dev: Bugger. What do we do?
Me: We can talk about anti-automation techniques and the trade-off between security and usability. Moving on, how are you going to store their password?
Dev: Oh Iíll encrypt it with a hash!
Me: Which one?
Me: Are you going to encrypt it or hash it?
Dev: I mean Iím going to use SHA1 with a salt so yeah, Iím going to hash it.
Me: Righto, so you realise that a salted SHA1 hash is pretty much useless right?
Dev: Ah, but itís a one-way hash so you canít un-hash it and rainbow tables wonít work because it has a salt.
Me: Yeah, but when you can compute 30 billion (thatís right, with a ďBĒ) SHA1 hashes per second with consumer hardware, cracking even salted hashes is a cinch.
Dev: Uh, rightÖ
Me: No dramas, there are much stronger alternatives available we can talk about. What about the logon Ė you going to allow multiple simultaneous sessions?
Dev: I hadnít really thought about that Ė should I? Whatís the problem?
Me: You should think about it then consider if it actually matters given the nature of your app Ė in many cases it doesnít. What about brute force protection on the logon?
Dev: That one is easy, Iíll just lock the account out if there are 5 failed attempts!
Me: So I can lock anyone out of their account if I know their username?
Dev: Good point, how about this Ė no lockouts!
Me: Well no lockouts can be good if you have other mitigations in place, but what happens if a bot starts hammering your service with millions of logon requests?
Dev: HmmÖ Iíll have a black list of IP addresses and block any that show suspicious activity like that.
Me: So what if itís a botnet distributed across tens of thousands of IP addresses?
Dev: They do that?!
Me: Yeah, itís a thing, weíll should talk about rate limiting and service degradation later on. Thereís a bunch we can do around fraud detection and prevention as well. You going to allow a ďremember meĒ feature?
Dev: Isnít doing that a security risk?!
Me: Thatís a relative question Ė it can be in certain scenarios but itís a pretty critical component of the user experience in other scenarios; security isnít just all about making things hard on people you know!
Dev: Gotcha, we can look at encrypting the username and password with Base 64 and putting that in a cookie then when the user comes backÖ
Me: Yeah, no! Iíve seen that done many times before but just no! Letís move onto changing account details Ė can users go back in and edit the info they provided at registration?
Dev: Yep, and I know where youíre going with this Ė they canít change their password without providing the old one first so thatís secure.
Me: What about their email? Can they change their email without providing the original password?
Dev: Yeah, but that wonít let them change the password!
Me: Youíre gonna build a password reset feature right?
Dev: Oh course!
Me: Where are you going to send the reset email to?
Dev: Oh crap. Ok, weíll request a password confirmation for an email change too.
Me: Cool, now how are you going to handle it if the attacker already has the userís credentials?
Dev: Well thatís not going to happen because youíre going to help us secure the system and they wonít be able to get them out from anywhere!
Me: True, but what happens when theyíve reused their credentials elsewhere and then theyíre breached and dumped publicly? Or thereís a successful brute force attack on another system and the attacker gets their creds from there?
Dev: Well thatís just sloppy behaviour on behalf of the user so itís their problem!
Me: Perhaps, but if an attacker uses those creds to compromise an account on your system you know where the user is going to lay the blame, right?
Dev: But thereís nothing you can do about that Ė itís game over once their username and password are leaked!
Me: Not quite, we can use other verification channels for key account activities such as changing attributes which would enable account takeover. How are you going to tackle the password reset feature?
Dev: Iíll just email the existing password.
Me: You canít do that because youíre storing it as a cryptographic hash which canít be reversed.
Dev: Ok, Iíll just email a new one then.
Me: Well you canít really do that either because now youíre sending it to someone over an insecure channel and then persisting it in insecure storage.
Dev: But Iíll tell them they should change it right away Ė itís in their best interest!
Me: Yeah, but they wonít, plus this locks them out of their account until they retrieve the new password so an attacker can DoS the victim just by initiating the reset process.
Dev: Youíre not leaving me with many options here!
Me: Itís not actually hard, we just need a time-limited nonce in a link to the site that grants them the ability to set a new password. What are you going to do if someone enters an email that doesnít exist in the reset feature?
Dev: Well Iíll have to tell them thatís an incorrect or non-existent address.
Me: And thereís your enumeration risk again Ė youíre disclosing information about who has an account on the site and who doesnít and that creates a bunch of privacy risks.
Dev: You just like making life hard on me, donít you?
Me: Itís actually not hard, we can use the same email channel to either initiate the reset process or advise the user that they donít have an account on the system. Letís move on Ė how are you doing logoff?
Dev: Well fortunately thatís one you canít do insecurely! Itís just a page that expires the auth token therefor logs them out.
Me: Ok, so thatís just an HTTP GET to something like /logoff right? How are you going to mitigate against the risk of CSRF?
Dev: Thatís not really a risk though is it? I mean what can the attacker get?
Me: Well if itís just a GET request to a resource then the attacker could always stand up a page that embeds that path in an iframe or even as the source of an image and if the user loads the page, theyíre auto logged out.
Dev: Is that really a risk though?!
Me: Depends on the system; it can effectively be a denial of service attack if the attacker can get their page loaded on the victimís browser and, say, cause it to keep hitting the logoff path by way of a meta refresh so that theyíre logged out almost immediately after logging on.
Dev: But youíve still gotta get the attackerís page loaded in the victimís browser, how are you going to do that?
Me: Heaps of ways, for example tweeting them a link with something alluring like the promise of a free pass, sending it via an email phish or even serving it via an ad network with malicious script. It happens enough that CSRF is still up there in the OWASP Top 10.
Dev: So you just make the logoff a POST request then and youíre done?
Me: Thatís not enough on its own, you need to protect this attack in the same way as youíd protect from any other CSRF attack and thatís by using anti forgery tokens. Itís a piece of cake and most frameworks have native constructs to help you with it.
Dev: Ok, so at least thatís it right? All good? All done?
Me: WellÖ thatís the fundamentals but there are a heap of additional considerations. For example, have you thought about using an identity provider like Microsoft Azure Active Directory or even OpenID Connect so that you make a bunch of this someone elseís problem? Ok, they have their downsides too but itís worth considering.
Dev: I like that ďsomeone elseís problem bitĒ! What else?
Me: Have you thought about using a web application firewall, perhaps via a service such as CloudFlare? It doesnít entirely get you off the hook security wise, but it can be very advantageous not just for security, but for performance too.
Dev: Interesting. Pricey?
Me: Well it starts at free and works up from there so not necessarily.
Dev: Oh Ė speaking of additional defences, what about two factor authentication?
Me: 2FA or two step auth can be awesome defences, but you know thereís a risk where the attacker can lock the victim out of their account, right?
Dev: Hang on Ė 2FA isnít just all rainbows and unicorns?!
Me: Nope, and while youíre getting your hopes dashed, remember you also want to have a think about how you protect the account management facilities from attackers inside the organisation.
Dev: Ah, but everyone I work with is very nice and trustworthy!
Me: They probably are, but that doesnít mean they might not end up with malware on their machines and serious problems Sony Pictures style. The design of your account management facilities and how you approach the principle of least privilege can have a big impact on just how bad it gets in a scenario like that. Oh Ė and while weíre not trusting people, you also want to consider how youíre going to protect against the threat of customers of the site being lured in by social engineering attacks such as phishing emails so yeah, youíve got a bit to think about yet.
Dev: Ok, that is seriously not my problem!
Me: Well weíre back to the earlier point about their sloppy practices potentially making your site look bad as thatís where they first see the risk surfaced. Thereís much more to security than just technical controls, you need to consider the social aspect and how views like this might adversely impact you.
Dev: So now Iím a bit scared about how much I hadnít really thought of that goes into these features!
Me: Better scared now than remorseful later
|You can see where I got my remark from in my earlier post|