Password Discussion

In a previous blog, I wrote about some routine training courses we need to do each year. I briefly discussed some security questions but there is one example I forgot to add. One course we did, my manager was raging that he got one of the questions “wrong” and he seemed more annoyed that he knew this course was one that NHS staff must also do. He Googled the question to see if anyone was complaining, and he found a post on stack exchange.

The question is as follows

Which of the following would make the most secure password? Select one:

a. 6 letters including lower and upper case.
b. 10 letters a mixture of upper and lower case.
c. 7 characters that include a mixture of numbers, letters and special characters.
d. 10 letters all uppercase.
e. 5 letters all in lowercase.

The answer we went with is B, because it’s the answer that contains the most characters, and as a bonus, has a mix of upper and lowercase.

However, this is apparently wrong, and we should have chosen C.

The Stack Exchange user, Robin Winslow, then referred to the famous XKCD comic, which illustrates what is now commonly thought of as the best type of password.

The key thing is that a password is useless if the person cannot remember their own password, and forcing complexity at the expense of this fact means the person is then most likely going to write it down. Additionally, forcing certain types of characters into the password also makes it more predictable.

If you ask me to choose a password, I may choose a memorable word, eg “programming“.

If you tell me I cannot have that because it needs to have an uppercase letter. I could add another character, or choose a random existing character to be uppercase, but that makes it hard to remember, so I am gonna choose “Programming“.

Then if you tell me it needs to have a number. Again, I could add a number somewhere in there, or substitute a letter, but that can be hard to remember, so I am going to put it on the end. There could be a significant number to me, or I can just choose the number 1 and put it at the end, because that is easy to remember, or easy for me to guess that I did that. So now it is “Programming1“.

Exactly the same thing happens if you tell me it has to be a special character. Probably end up choosing “Programming!1“. It has more characters than my initial password of “Programming” but it’s at the expense of memorability.

Another aspect to consider is password expiry. At work, we used to have to change our passwords every three months, but now it’s currently six months. However, what’s my next password going to be? Probably “Programming!2”. So if the aim is to stop people accessing the system if they somehow got my old password, they still will get in because they can just guess the new one.

I wasn’t sure what the rationale was to change the expiry from 3 to 6 months because if you think it’s not a great feature, then you would just outright remove it. When the Head of Security started working for us, the first thing I saw him do was walk away from his laptop without locking it – so maybe that illustrates how good his skills are.

Troy Hunt points out that Microsoft’s latest policy is to not use expiry at all.

Research has found that when periodic password resets are enforced, passwords become less secure. Users tend to pick a weaker password and vary it slightly for each reset. If a user creates a strong password (long, complex and without any pragmatic words present) it should remain just as strong in the future as it is today. It is Microsoft’s official security position to not expire passwords periodically without a specific reason, and recommends that cloud-only tenants set the password policy to never expire

Microsoft Azure

Troy makes some follow-up points

Geez there’s some debate about this one! Mostly support but also some misunderstanding so let’s fill some gaps: Firstly, password managers don’t solve this problem, not when you’re talking about the credentials to logon to your PC. That’s a rare case where you need to type it…

…unless you’ve gone passwordless via security keys, biometrics etc. Clearly this negates the need to use the password with such frequency thus reducing the opportunity for compromise. There may still be a password (e.g., fallback from biometrics), but exposure is much less.

The argument of “well what if the password is exposed a year later” could just as easily be “well what if it’s exposed a month later” when there is a 90 day rotation cycle. Different windows of risk, so why not make the cycle a week? Because it’s painful…

…plus, the solution is the same: MFA. The usefulness of a password alone for AD login has dramatically reduced with the mass adoption of multi factor. Mandate it on your AD tenant and the value of rotation dramatically reduces.

Troy Hunt

Also, there are always ways around policies for those more-determined users

I used to be at a company that did that. Someone quickly came up with a script that changed the password ten times in a row and set it back to the original (last ten passwords were not allowed).

Kerry W. Lothrop (https://twitter.com/troyhunt/status/1578149402304094208?s=20&t=Uk9uhXXLK2vPj2EA_pE4uw)

I’m not sure I 100% agree on the “well what if the password is exposed a year later” point. Expiry does remedy that in some cases but no expiry will always leave you vulnerable. You are relying on knowing there has been a breach.

Troy Hunt has discussed that the best security involves a mixture of methods. It generally comes down to

  1. Something you know
  2. Something you have
  3. Something you are

Aaron Toponce did recently post on Twitter about this, but his account has since been deleted. This is why dumping things into OneNote is useful. Troy Hunt has also discussed this idea many times.

Not sure what Taylor Swift has got to do with it. Maybe she pretends to be happy.

So if your account has all 3 types associated with it, even if someone knows your password, they cannot get in because they will need your token (Authenticator app on your phone). If they have managed to also steal your phone, then they can’t get in if they also need your fingerprint. If they are holding you at gun-point to make you unlock your account using your finger, then you have bigger problems.

Aaron’s musings was this:

If a password is stored in a password manager, is it still something known, or does it become something possessed? A password manager vault can be stolen.

Knowledge of where the passwords are stored and how to retrieve them then becomes “something known” and the vault itself “something possessed”. No?

Aaron Toponce

This has since become quite topical in the recent LastPass breach where keyvaults have been posted on hacking forums. If the master password is then cracked, then hackers will have access to many people’s accounts. I was always intrigued by password managers, but I did feel you really are putting your trust in one company.

State of Js

I drafted up this blog a year ago but never published it.

State of JS” do an annual survey about Javascript, and one of the questions was about people’s favourite content authors.

In the 2021 survey, 2 out of 15 of these content authors were women, and some of the “Social Justice Warriors” aren’t happy about this, so one of them stated that the chart’s title should be simply “MEN”. Then she follows it up with highlighting the demographics of the people surveyed. 71.3% were men, 4% women, 0.9% non-binary, and everyone else refused to answer.

I think her point is that men are voting for men and thus perpetuating the “bro culture” that is holding back women like her.

If we assume that the survey does represent the proportion of developers (after-all, it is well known that the software development industry is mostly men), then I would say that should be proportionate to the number of public content creators too.

Therefore, we should only really expect to see 4% of women occupy the Top 15 Content Creators list. So what is 4% of 15? Isn’t it 0.6? So really, it’s not even that farfetched to expect all 15 to be Men.

It’s possible there are more women since there’s that large number of people who opted not to specify. However, around 492 women did respond, so there could easily be more women on that list. What’s that you say? Women are probably nominating men?! Unheard of!

I only learned some Web Development stuff HTML, Javascript, Typescript, React over a short period, and if you asked me to name some creators, I’d have probably named Dan Abramov, Wes Bos, Florin Pop, and Stefan Baumgartner and Cory House. Kent C. Dodds, Dan Abramov are big names in the field and the likes of Wes Bos have a huge following, have paid content, are very active on Twitter, and have a Podcast. So you expect these names to occupy the top spots of a list like this. Is it really perpetuating an exclusive culture?

I think it is just simple statistics. There’s no point lambasting StateOfJs for putting a survey out there. There’s no point attacking the men who responded that they didn’t vote for your friends.

I’ve written about a few occurrences like this. Deep down, these people think they are doing good by going on the offensive and “virtue signalling”, but all they are doing is creating a divide/toxic culture which is the opposite of what they actually want.

Note: It looks like there are 5 women on the latest survey https://2022.stateofjs.com/en-US/resources/. I wonder if this is linked to last year’s outrage, or mere coincidence.

Bug Bash

It’s been a while since we organised a “Bug Bash”. The general idea is to focus on fixing software bugs and clearing the seemingly ever-growing list. Sometimes managers have organised this as an optional thing over a weekend, or sometimes opted for a work week.

The problem I have with this idea is that with a strict deadline, you are encouraging people to rush. If you want to follow the usual process of a developer really understanding the bug (reading the bug report carefully, recreating the issue, analysing the code, coming up with a solution, testing it manually, maybe writing some unit tests for it), then going through the code review and testing process – then you are being really hopeful that it can be done in such a strict time-frame.

I find another developer will always have some opinion on your code, so you make a change, have to retest it and then get them to review it again. Then when coming to patch it on the test environment, you then might get problems with the build server or the test environment.

So the only bugs that are really appropriate for a Bug Bash are ones that are easily recreatable, quick to fix, and low impact. All the true high priority issues will have been addressed more urgently and put into the normal release process anyway.

What you have to bear in mind, is any change has some kind of risk that you might introduce another problem, and this increases when you try and rush the change out; which is what the Bug Bash inherently prioritises.

I was looking for an example of how managers sold the idea, and I found one that actually seemed a bit more thought out:

 
Next week we are to down tools on project work and spend the week stabilising our product.
 
Service have provided a list of 300+ issues they would like us to work through. In addition, Paul has been reviewing the Error Logs to identify the most frequently reported errors and is creating items for these.
 
The domain experts are currently reviewing the list and identifying the issues they feel can be fixed next week. These will be placed into the Stabilisation list.
 
The priority order for working these items is set by a temporary field ‘Bug Fix Priority’. 1 is the highest priority.
 
Each developer should select the next bug at the top of the list that is not currently being worked, change the state to Assigned, and Owner to themselves.

All Priority 1s must be completed first. If there are no defects you are comfortable fixing, please speak to me before moving on.
 
Each bug fixed must have supporting unit test(s) before being sent for code review.
 
At no point should a developer have more than 3 items they are involved with, this being 1 bug being worked on, 1 being code reviewed and 1 with the tester.  If you’re waiting for a code review - go chase it. If you're waiting for a test to complete – go help out.
 
It is important to note the emphasis on this release is QUALITY.
 
With this in mind, the attached spreadsheet has been produced that maps a developer to someone who will review their code and DB changes. Where possible we have also mapped each developer to a test resource. The developer and tester jointly own the end to end process for each bug.
 
A kick off meeting will be held at 10am on Monday in Room 1 for all to attend.
 
Code Reviewers will hold daily stand-ups with their development and test resources which will then feed into a management review at 4 pm.
 
 
Darren
Development Manager

So, they have allocated a full week, tried to analyse the bugs to see if they are suitable to fix quickly, and they have emphasised it is about quality. However, they seem fairly strict on the order the bugs are addressed, so you may end up with developers being forced to pick up items in areas they don’t specialise in.

There was a follow-up email stating that there were issues with the build server which caused them to lose time.

All,
 
The plan is to finish coding tomorrow to allow test to complete on Friday.
 
With this in mind and as a result of build issues experienced yesterday we’re considering the possibility of overtime tomorrow evening to make up lost time.
Can you please indicate using the voting buttons by 12pm tomorrow whether you’d be available for overtime tomorrow evening.

We'll be ordering Pizza and a Beer too, to keep us fuelled 😉 It would be very much appreciated if you could stick around. Every bug fixed is giving our end users a better customer experience!
 
Thanks,
 
Darren

When Bug Bashs have occurred over the weekend, I think Developers and Testers have started at the same time, but they wouldn’t have had anything to test until mid-day at least – due to development time, code review time, then build and patch process. So the Testers will just be earning money for chilling out and eating pizza.

I found an instant messaging conversation with a colleague about a different Bug Bash:

Daniel 11:37:
one of the bugs on the list to be fixed in the bug bash was logged by me 5 years ago
so very urgent then

Me 11:38:
the bug bash isn't supposed to be for urgent issues

Overtime requests will only be approved for time spent on defects that are Fixed, Tested, PO Approved and Closed(Done)
 
So you could do some complex work, not get it done, and therefore not get paid

Daniel 11:42:
yeah I read that today
who's going to go for that
it's completely the wrong way to fix bugs

So this bug bash seemed to be for clearing down all the bugs that have just been ignored for years. The problem with old bugs like that is that you could spend time trying to recreate them, and find they are now obsolete due to other code changes, or obsolete features. The managers also decided they didn’t want to pay people for incomplete items, so you cold spend ages working on something and not get paid.

  • You could close the bug as obsolete – it’s not fixed so you don’t get paid
  • You could spend ages recreating it, coming up with a fix, but there’s not enough time for the rest of the process to actually complete it.
  • You could come up with a fix, but there’s a small bug found by the tester. You could persuade them to keep quiet so you both get paid.
  • You could come up with a fix, but build issues cause it to not get tested.

I think that every-so-often, you do need to analyse the list of bugs you have, and try and clear it down; either by fixing them, proving they are obsolete, or maybe just marking them as never intending to fix. A dedicated period of time is required but I would have thought a 2 week period is required at minimum in order to not cut corners.

Software Support Call Centre

We used to have a very large support team in our own call centre. As a software developer, we were occasionally sent to go talk to them from time to time, and I was amazed at how busy they were. Usually, as soon as they had put the phone down, they had another user call up.

Sometimes it was that the user just didn’t know how to use the system, and other times it was to complain about a software bug or slow performance. The call centre staff were rapid at entering the information into the system, and were brilliant in asking the user the right questions to really understand their problem. They could often tell the user if the issue was logged or not, and also give them some relevant work-arounds. 

After speaking to some of the staff, they explained how strict the culture was there – they were monitored on how fast they picked up the phone, how long the call was, and how many breaks they had. They said how annoying it was to be warned about being late when it was due to bad traffic.

It surprised me because it seemed a completely different culture to how the development department is run. We are flexible when we start; so you can just turn up late and no one cares. We were never challenged on how long our work took to complete. I guess if our work is poor quality, it’s the call centre staff that took the complaints!

At some point, some manager decided to use a 3rd party company for Support, and most of our Support staff either left or (presumably) got redundancy.

The amount of complaints seemed to go up on various social media platforms, and I got the impression this 3rd party company didn’t know our software so were just providing users generic statements from a script “can you try turning it off and on again?”. Maybe if they got past the initial questions, they then got put through to our smaller 2nd-line Support team.

A few years later, I think a new manager came in and decided to try to reverse the decision, but it’s going to take a bit of time to get the new staff as good as the old ones.

“As part of our drive to strengthen our customer satisfaction and experience along with simplifying our ways of working for both our customers and the service desk, the decision has been made to insource the call centre. All calls will now come directly into the service desk.

We have already run a couple of trial switch offs over the last fortnight and the initial feedback has been unanimously positive with customers preferring to be directly connected to the service desk; just in this small sample there has been an increase in both the quality of cases and first-time fixes. We will continue to invest in developing a world class service desk.”

Company Announcement

It seems obvious to me if you make the support more generic, then it’s going to decrease customer satisfaction.

The only problems I had with Support is:

A) when they would link completely different issues to the same bug report. Sometimes you see that a bug that you thought should be super rare – has had 100’s of reports from the users. Then when you look into the cases, you see that 90%+ of them are unrelated. We could have probably put some advice on how to decide if issues are the same root cause or not, in order to try to help remedy this.

B) Sometimes there’s other data entry errors that end up being misleading, like this:

Support (in the free-text description): 
"however we have been able to re-create this on the test system by"...

also support (in the mandatory fields):

"Recreated in-house: No
Reason not recreated: Unable to recreate"

The DockerCon Proposal

We had a Senior Software Developer join us a few years back and he seemed obsessed with “networking” and also using “new technology“. By “new technology”, I mean if we weren’t already using it, he wanted to use it, so was pushing to use Docker. And by “networking”, I mean going to nerd conferences and events.

“Is anyone thinking of going to DockerCon? Seems like the kind of thing we should get some skin in the game?”

Senior Developer

I’ve never heard of that phrase “skin in the game” before, but my biggest question is “how long can people talk about Docker for?” People from all around the world, going to Barcelona to talk about what things they have docked.

I don’t often see a benefit of these conferences anyway. People do mention “networking”, but what do you really do? Talk to random people, boast about how good you are, and hope that if you apply to the company they work for, that they are the ones looking at your application, and also remember your name and who you were? If not, it probably isn’t increasing your future job prospects.

You must think it is very beneficial if you are travelling from England to Spain just for a conference, but this developer was well up for it. I suppose if he could convince the company to send him, then it’s a free holiday, so maybe you don’t know how sincere he is.

In my previous job, we were in the gambling industry. There was some event down in London, something like the “International Gaming Exhibition”. It was for companies in the gambling industry to show off their new products. There were loads of slot machines, fancy roulette wheels, all kinds of automated machines (card shufflers, automated roulette wheels).

I had no idea what our objective was really, so I just walked from stall to stall, taking all the free stuff. I got a couple of tote bags; stationery items such as pens and post-it notes; and playing cards. Our company was essentially rivals to some of these companies so we weren’t there to buy, and we didn’t have our own stall so we weren’t there to sell.

Some of the stalls were very elaborate and like those ones they used to have at E3 before that sort of approach was deemed sexist. So some stalls were occupied by bikini-clad “booth babes”. You could say those companies are getting some “skin in the game”! I thought they must hire them from some modelling agency or something, but it was interesting hearing them answer fairly technical questions about the products – so they must have done their homework. One company was spraying their woman in full body paint. I got there when she was about 90% painted, but one of my colleagues was boasting about how he got there earlier. This was probably around 2011 so I would imagine those “booth babes” might be cancelled, like the ones at E3.

KFC Message Fail

If you have KFC’s app, they will often give you notifications on offers. Just like some other food businesses, they have been doing offers on special occasions. So if it’s the World Cup final, they may tell you that you can celebrate with a Bargain Bucket etc.

This feature was in the news recently, when the special occasion was actually a negative event.

Snopes covered the story, https://www.snopes.com/fact-check/kfc-kristallnacht

When translated to English, the message from KFC read, “It’s memorial day for Kristallnacht! Treat yourself with more tender Cheese on your crispy Chicken. Now at KFCheese!”

Kristallnacht, when translated, means “Crystal Night.” It refers to Nazi Germany’s persecution of Jewish people on Nov. 9-10, 1938. 

Snopes

Snopes was given the following explanation:

On November 9, an automated push notification was accidently issued to KFC app users in Germany that contained an obviously unplanned, insensitive and unacceptable message and for this we sincerely apologise. We use a semi-automated content creation process linked to calendars that include national observances. In this instance, our internal review process was not properly followed, resulting in a non-approved notification being shared. We have suspended app communications while we examine our current process to ensure such an issue does not occur again. We understand and respect the gravity and history of this day, and remain committed to equity, inclusion and belonging for all.

Snopes

I think it’s a good example of why even simple automated features like this need to be manually reviewed. However, despite KFC saying the promotion should be manually reviewed, they somehow still published the message.