Skip to main content

Password Trash

We know passwords aren't great and that people choose crappy short ones that are easily remembered given half the chance. The solution to which seems to be to ask for a least one number, one upper case char, one symbol and a minimum of 8 chars...

However, you don't want to use the same password everywhere as the majority of sites aren't trustworthy* so it's foolish to use the same password on all of them. The result is an ever mounting litter of passwords that you can't remember and either end up writing them down (which likely violates terms of service and makes you liable in the event of abuse) or rely on "forgotten password mechanisms" to log in as and when needed (the main frustration here being turnaround-time and the need to come up with a new bloody password each time).

Yet using 3 or more words as a passphrase is more secure than a short forgettable password and would make a website a damn sight easier to use - you still can't use the same password everywhere though. It's about time we started making minimumpasswordlength 16 characters and dismiss the crypto garbage rules that don't help anyone.

Facebook, Google and the like would have you use their Open ID Connect services - this way they effectively own your online identity - and, if you do use them, the multi-factor authentication (MTA) options are well worth adopting. Personally I don't want these guys to be in charge of my online identity though (and most organisations won't be either) so whilst it's ok to provide the option you can't force it on people.

We need to continue to support passwords but we need to stop with these daft counterproductive restrictions.
* Ok, none of them are but some I trust more than others. I certainly won't trust some hokey website just because the developers provide the illusion of security by making my life more complicated than is necessary.


Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.