Use the steel carabiner!

Posted on by
Reply

“It’s stronger.”

As I’ve mentioned I’m an instructor with the National Cave Rescue Commission. During our classes we teach a variety of skills using a variety of equipment. Among the equipment we use are carabiners of various sizes and materials. The two most common materials are aluminum and steel.  Each has its advantages and disadvantages.

Aluminum is almost always lighter and this can be a real advantage when you have to carry a lot of them.

An aluminum carabiner may have a MBS (mean breaking strength) of 20kN (kiloNewtons or about 4,500lbs) along its long axis. (Different designs and different manufacturers will have different values, and orientation can make a huge difference).

A steel carabiner may have an MBS of 25kN along the same axis. So, it’s obviously stronger.

But here’s the thing. When we’re moving a patient, we have to look at the entire system.  In the NCRC we call this the system safety ratio (SSR).  You can’t look at just one component. Imagine using a carabiner (steel or aluminum) and trying to haul a patient with dental floss. It doesn’t matter what carabiner you use, that dental floss won’t get you very far.

And honestly, if you’re at the point where the strength of the carabiner is that critical such that the difference between 20kN and 25kN is critical, I would recommend you review your entire system.  There might be a better way of doing it. But yes, sometimes you MIGHT need that extra strength.

That said, why do students often reach for the steel carabiners in some cases? It’s not strength. It’s size and durability. Generally the largest carabiners we have are steel and they work best in the eyeholes of the Ferno litters we use. The Ferno has a load limit of approximately 2.6 kN. (Note how much less this is than the carabiners holding the litter! At this point 25kN vs. 20kN isn’t really important).

Besides fitting better, the steel carabiners tend to be more resistant to dings and scrapes and other forms of damage. In other words, it’s not as simple as “use the stronger one”.  It’s more complex and really comes down to “use the one that best fits the situation.”

I’ve mentioned previously the use of passwords and how we have rules we often follow in regards to them. I think it’s always worth understanding the WHY of rules and when to best apply them. For some accounts, I might have an easy to remember password because if it IS breached, the harm will be negligible.  For example, I’m a moderator for the sci.space.tech group on USENET (look it up if you’re below 40!). I have to log in about once a week to moderate an article. That account has a fairly simple password because in the worst case scenario, if someone DOES breach the account, the most they could do is… approve the 1 or 2 articles that come in each week. So it’s a password that’s “secure enough” (i.e. nothing anyone is going to guess from knowing me) but easy to remember.

On the other hand, the login for my E*Trade account is far more secure because if someone could access that, I could lose a lot of money.

So it’s not always “use the stronger one” it’s “use the one appropriate to the situation.”

This applies to many areas of life.

DTSX Error

Posted on by
Reply

Not really a blog post of the typical form, this is more so add content to the Internet and hopefully have Google find it for someone else.

So, I inherited a DTSX package from a former project. Who hasn’t been in that position before, right?

No problem I could make most of it do what I wanted except for ONE Data Flow Task. Or more accurately, ADO NET Source.  This was connecting to a 3rd party database on the client server.  Not a problem, except I can’t hit that 3rd party database from my desktop and, unfortunately, I can’t install Visual Studio on the client’s server. So, for most of my changes, I had to disable that data flow task to make my other edits.  Annoying, but not a show-stopper in this particular case.

Until… I had to actually edit that Source.  I could not add new OUTPUT Columns under the Source Output.  I think this is because I couldn’t connect to the actual data source to validate stuff. I could be wrong. But anyway, I had to resort to editing the XML directly. This is always a bit dangerous, but Danger is my middle name. (Ok, maybe not, but my middle initial IS D.)

And then I committed my changes, loaded it to the client computer and ran it.

Well, sort of.  The data flowed like it should and then I got:

System.NullReferenceException: Object reference not set to an instance of an object.   at Microsoft.SqlServer.Dts.Pipeline.DataReaderSourceAdapter.PrimeOutput(Int32 outputs, Int32[] outputIDs, PipelineBuffer[] buffers)  at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostPrimeOutput(IDTSManagedComponentWrapper100 wrapper, Int32 outputs, Int32[] outputIDs, IDTSBuffer100[] buffers, IntPtr ppBufferWirePacket)

The other error was:

SSIS Error Code DTS_E_PRIMEOUTPUTFAILED.  The PrimeOutput method on ADO Source returned error code 0x80004003.  The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.  There may be error messages posted before this with more information about the failure

I added some more error handling and tried everything, but, I couldn’t stop the error, even though all the data actually was flowing.  This was weird. The data WAS flowing exactly the way I wanted. But, the package would fail due to the above error.

I finally created a test package with JUST the Data Flow Task and tried debugging that. I still had no luck. But at least the XML was far easier to parse.

After looking at it for the 42nd time, I finally noticed… I had added the column to the Output Columns under the ADO NET Source Output, but I had NOT put it under the ADO NET Source Error Output.

So, even though there were no errors, apparently DTSX would still fail because of the missing column. Once I added that, everything was solved.

 

Followers and CPR/First Aid

Posted on by
Reply

Yesterday, I performed a little social experiment and was pleased to find it worked. I’ve got to say, sometimes it’s the small things that make me happy.

Despite the below zero (Fahrenheit, so really cold, not that warm-cold of 0°C) temperatures, my son and I decided to head up to a local state park and do a hike.  Surprisingly, OK, maybe not, when we arrived, the parking lot was completely empty.  It had been plowed, but there was still a layer of snow over the entire thing, so it was impossible to see where the parking lines were. Now in the summer, this parking lot can be completely full, but I wasn’t too worried about that occurring when the temp was about -4°F.

So, which way to park? Well, there was some sun, so I figured I’d park so that the windshield would get the most sun and hopefully warm up the car just a bit while we hiked. I was sure at the time and later confirmed, this was at a 90° angle to the way the parking lines run. Ironically it was also about 90° colder than the summer temps!

Even when we started hiking, no one else had shown up. But, I have to admit, in the back of my mind I had to wonder if I would start a trend.

Sure enough, 1.5 hours later, when we arrived back at the car there were 3 other cars.  Not only were they parked in the same orientation, they were all parked right next to my car.  This parking lot probably covers 3 acres. They could have parked pretty much any place they wanted in any direction they wanted. But, because I had randomly picked a spot (and not so randomly a direction) 1 car was parked next to me in the same orientation and the other 2 parked facing us.

So what does this little experiment have to do with First Aid or CPR? Have you ever been at an event when someone has a medical event and at first no one reacts? It’s actually fairly common.  Everyone is standing around waiting for someone else to react. But once someone reacts, others tend to follow.  Be that person that others follow.  Learn CPR and learn First Aid so that when something happens, you can be the first to react. Sometimes people just need a leader to follow; and often they don’t necessarily realize it.

There’s no good reason anyone else parked just like I did, and yet they did. But there is a good reason for people to follow you if you can be the first to react in an emergency.  And you don’t have to be an expert. Obviously it didn’t take “expertise” to park yesterday, but people followed anyway. You don’t have to be an EMT or paramedic to react at a medical emergency. You can be the person that simply shouts, “Call 911” and gets people reacting.

That said, I still highly recommend taking a CPR and First Aid course. Not only do you learn very useful medical response skills, it will help you be that person that reacts first.

And stay warm!

Barriers

Posted on by
Reply

Years ago, I had my team building out our racks at our new datacenter. I was quite proud of it. It was going to be our first planned from the start build-out of 6 racks, as opposed to the hodge-podge build-out we had done of 5 cabinets we had previously rented. Instead of just cramming in equipment where it would fit, we could plan where every piece would go and where we’d leave room for future expansion. This was in 2001, so it was still during a big Internet boom.

One of the things I had decided on doing early on was color coding cables. Red was for anything in front of the firewall for example.  On the backside, every server had two network cards, one for outgoing traffic (the “front-net”) and the second for traffic between the servers (the “back-net”).  To help distinguish between the two, I had ordered a bunch of green cables for the front-net, since that data was “safe” and green is “safe”, and blue cables for the back-net, both start with “b”. Sure, somewhat silly mnemonics, but they worked.

Until, about a week after we finally completed our datacenter move, not one, but two members of my five person team commented, “oh, they were different colors? I couldn’t tell, I’m colorblind.”

“Doh!”  So much for my nice color-coded system.  It can be fairly easy to overlook barriers when you don’t see them. Sometimes it takes more thought and action on your part. Sometimes it takes asking questions, or observation.

Lately I’ve been trying to look for more barriers that I might not have seen before and looking into what I can do to remove them. I’ll be the first to admit, I’m not always successful and I’m still learning. But hopefully we call can.

One area I’ve been focusing on this is in my work for the Capital Area SQL Server User Group. Right now I’m looking at two possible barriers. I say possible because I honestly don’t know if they’re issues or not:

First, I’m trying to find someone who can provide ASL interpretation.  Here’s the thing: we have never had, as far as I know, a deaf person attend one of our events, or even express an interest. Is that because there are no deaf DBAs in the area or because they know if they do attend, they probably will face barriers an person with hearing won’t face?

But, that actually begs the question: if there are no deaf DBAs in the area, why? Perhaps there are deaf people who WANT to become a DBA, but can’t because the barriers that exist well before they even attempt to attend one of our events.  I don’t know, but I hope to explore this issue a bit more.

Another item I’ve started to look into, is whether some sort of child-care services at our SQL Saturday event would help encourage more people to attend. My initial thought is, “it’s Saturday, so ideally a spouse can watch kids” or a similar solution. But, that’s assuming every attendee has a spouse or the extra money to hire a babysitter for an entire day. In other words, it’s making a lot of assumptions.  There’s definitely some major logistical concerns that I have to continue to explore before we can even think about offering it. But I’m also simply trying to figure out if it would make a difference.  Unfortunately, currently for our user group meetings itself, it would not be practical. But even then it may be worth looking into.

On a personal note, I have a friend who had a service dog. She was interested in joining me on a caving trip.  So we actually discussed the logistics of it and determined that it was in fact possible to take her caving with her service dog.  There was some logistics we had to work out and I did have to get permission from the cave owner.  Unfortunately, our scheduling never quite synched up and we had to forego the trip. But the point is, barriers CAN be overcome if one works at them and is willing to be a bit flexible.

Today’s takeaway: What barriers have you looked for and tried to remove? They’re out there, even if you can’t see them.

 

Moving the Needle – Hard

Posted on by
Reply

One of the things I enjoy is problem solving or “debugging”.  I don’t necessarily mean debugging code, though I’ve done plenty of that.  One particular class of problems I like solving is when something isn’t working “right”.  I’m currently involved on one such issue.

Just before the holidays, the lead developer at one my of my clients put me in touch with a team in another division to help them solve some performance issues they were having with their SQL Server. This is the sort of issue I generally like to sink my teeth into.

I started poking around and asking questions. I was a bit crushed when in the initial review they listed all the things they had tried and I had to nod my head sagely (which, being a remote worker went unnoticed by them) because they had tried all the basic things. They had, fortunately for them, ruled out a lot of the easy fixes.

So now it came down to some digging. I won’t go into too many details, but will cover some of the things uncovered and tried. For one thing, they have 44 SQL jobs that run every 20 seconds and basically do a poll of a database to see if there’s any work to be done. So, every 20 seconds 44 SQL jobs would fire up, do a quick select and then go back to sleep.  On their new server, they were on average taking 6 seconds a piece.  In addition, the CPU would spike to 100% for about 5-6 seconds and then drop back down. We are also seeing a lot of wait states of the MSQL_XP variety (accounting for about 1/2 the time the system is waiting and averaging about 61.1 ms each time. [Thanks to Brent Ozar’s script here!])

We tried three things, two helped, one didn’t.

First, I asked them to spread the jobs out. So now, basically 2-3 jobs are started every second. This means over a 20 second period all 44 jobs are run, but not all at once.  This had an immediate impact, the jobs now were taking about 2-3 seconds. A small victory.

Secondly, we changed the MAXDOP settings from 0 to 4.  This appeared to have no impact on the jobs. In retrospect makes a lot of sense. Each job is a separate task and basically single-threaded, so SQL Agent won’t care about the MAXDOP.

For those who aren’t familiar with SQL Server, MAXDOP is short for “Maximum Degree of Parallelism” This controls how much SQL Server will try to spread out a task among its CPUs. So for example you had 100 tests to grade and sort into alphabetical order and you had 1 person to grade them. That one person would have to do all the work. You might decide that having 100 people is 100 times faster since every person can grade a test at the same time. But then you have to hand out the 100 tests and then collect the tests and resort them back into alphabetical order, and this takes longer than you think.  So by playing around, you realize it’s actually faster to only have 10 people grade them and sort them.  In other words, sometimes, the effort of spreading out the work itself takes longer than the time saved by spreading it out.)

But, one thing that didn’t change was the CPU spike. But, since the poll jobs were twice as fast, we were happy with that improvement.

However, the real goal of the poll jobs was to wake up ETL jobs to handle large amounts of data. These were running about 1/2 as fast as they’d like or expected.

Here, MAXDOP does seem to have changed things.  In most cases, the ETL jobs are running close to twice as fast.

But, here’s the funny thing. I didn’t really care. Yes, that was our goal, but I’d have been content if they had run twice as slow. Why? Because at the point we changed the MAXDOP settings, my goal wasn’t to improve performance, it was simply to move the needle, hard.  What I meant by that was, by changing the MAXDOP from 0 (use all 32 CPUs) to 4 I was fairly confident, for a variety of reasons, I’d impact performance.  And I did in fact expect performance to improve.  But, there were really 3 possible outcomes:

  1. It improved. Great, we know we’re on the right track, let’s tweak it some more.
  2. It got worse. Great, this is probably NOT the solution, but let’s try it the other way and instead of 4 CPUs, try say 16 or even a larger value. At least we know that the MAXDOP is having an impact.
  3. Nothing change. In this case, we can pretty much rule out parallelization being a factor at all.

In other words by forcing SQL Server to use only 4 CPUs instead of all 32, I expected a change. If I didn’t see a change, one way or the other, I could mostly rule out parallelization.

Finally, once we saw that a MAXDOP of 4, we started to play with the threshold of parallelization. In this case we ended up with option 3 above. We tried a fairly small value (5) and a fairly large value (100) and haven’t seen much of a difference. So the cost threshold doesn’t seem to have much of an impact.

So, we’re not fully there yet, there’s a number of other factors we need to consider.  But sometimes when you’re approaching the problem, don’t be afraid to move the needle, in any direction, hard, can tell you if you should continue to try that approach. In this case with MAXDOP it indicated we were on the right track, but with the cost threshold, we’re probably not.

We’ve got a lot more to do, including seeing if we can eliminate or speed up the MSQL_XP wait states, but we’re on our way. (For the record, I don’t expect much change on this one, it’s really SQL Server saying, “hey, I called out to an external procedure and am waiting to hear back” so we can’t tweak the query or do other things that would make much of a difference.”

 

 

 

 

 

Janus 2 – 2019

Posted on by
1

“All my life’s a circle” – Harry Chapin

The New Year is now upon us. It’s now January around the world.  For those who don’t know where the name of the month comes from, or why my previous blog post and today’s are named as they are, it comes from the Roman God Janus.  Janus looked backwards and forwards. I thought it was appropriate for posts bracketing the New Year. In addition, the name of the month January is often believed to come from the name of the god, but that appears to be a false etymology.

Yesterday I looked back. Today, I’ll look forward.  I’m not necessarily a fan of New Year’s Resolutions (other than resolving to live one more year, which I’ve been successful at so far every time) so call these goals:

  • Continue to blog at least once a week. Last year I think I missed a week while on vacation, but otherwise I pretty much succeeded.
  • Hit 2000 page views. Last year I hit 1907.  I think I can exceed that this year. Of course I’ll need your help!
  • Continue speaking at SQL Saturdays. I haven’t set my schedule, but I already have 3-5 in mind. I’m not sure I’ll do 6 again, but we’ll see.
    • Expand my “SQL Server for under $200” session
    • Expand my “SQL Server Backups” (perhaps into a full precon)
    • Add one more topic to my list of sessions (see current ones here)
    • Shoot for at least one overseas engagement
  • Shoot for speaking at SQL Summit!
  • Figure out how to get an MVP!
  • Publish at least 3 more articles for Redgate’s Simple Talk
  • Continue to promote and support Women in Tech as well as other minority groups
  • Continue to learn PowerShell
  • Continue to learn about SQL Server on Linux
  • Play with containers, just a bit. This is really a minor goal given all the others I have, but I figure I should learn a little.
  • Pick up at least 1-2 more decent sized customers
  • Continue teaching cave rescue
  • Cave more!
  • Hike more!
  • Bike more!
  • Travel
  • Have fun!

That last goal is important to me. If I’m not enjoying what I’m doing, why do it? Life is too short to hate what you do with life. If you can find a way to enjoy life, do it!

Most of the goals above are SQL related, but that doesn’t mean that’s the major focus of my life. It’s just the place this blog touches upon the most these days.

I have a number of personal goals, but that’s for me and I won’t be sharing here.

In any event, I wish everyone in my biological family, #SQLFamily, Caving family, and other chosen families a wonderful and amazing New Year and hope that the new year brings you peace and happiness.

Janus 1 – 2018

Posted on by
2

As the year draws to a close, I thought I’d look back on the year a bit.

The goal of this blog has been to give me a place to reflect on the purpose of this blog.  I claim in My Goal Here to want to reflect on how we think and what drives certain decisions. And I suppose at times that’s true. At times it’s to give actual SQL or IT related advice.  But at times, it’s simply an exercise in my ability to put fingers to the keyboard and words on the screen and to be a bit self-indulgent if I’m honest.

My most popular page this  year was a mixture of things: The Streisand Effect. It was a bit of an activism piece about events at my alma mater and a chance to broaden my blog to more readers. But, it did also serve to actually reach one of my primary goals; to reflect on how we think and make decisions; primarily sometimes by trying to tamp down an issue, we only serve to draw more attention to it and to inflame things further.

My second most viewed piece this year was one of several on sexism, especially in the IT industry: Math is hard, Let’s Go Shopping. I still haven’t finished the book mentioned in the post, but it’s on my list to finish. The issue of sexism in my primary industry is one that has grown in importance to me and I expect to write more about it in the coming year and to try to do more about it.

Reviewing my SQL Saturday’s in 2018, I had the honor of speaking at Colorado Springs, or at least trying to, which I wrote about here; SQL Saturday Philadelphia, SQL Saturday Atlanta, SQL Saturday Manchester UK (my first overseas SQL Saturday, where I had a blast!), SQL Saturday Albany, and finally SQL Saturday DC. I also presented at the DC SQL User Group in September.  All great times and I had learned a lot and had a great time meeting new people and reconnecting with old friends.

I put in to speak at SQL Pass Summit, but again didn’t make it. But I still attended and had a great time.

I also was pleased to be asked to write for Redgate’s Simple Talk where I know have two articles published on using PowerShell for SQL: My first and second. I’ll be submitting my third article in coming weeks.

But not everything I did or wrote about was SQL related or even IT related. In late June, 13 people became trapped in the Tham Luang Nang Non cave in Thailand. This became a world-wide media event that a few weeks later I found myself part of. Besides at least four blog posts of my own that touched upon it, in my role as a regional coordinator of the National Cave Rescue Commission I did close to a half-dozen media engagements, including one for The Takeaway NPR program.

Oh, one more interview I did this past year was with Carlos Chacon and Steve Stedman of SQL Data Partners: it was a podcast I did with them. You can read about my thoughts here and listen to the podcast here. And definitely go to Amazon and buy my book!

Anyway, it’s been a great, and eventful year and I appreciate everyone who has read my blog and even more so to those who have commented on it, shared it, or somehow given me feedback.

I’m looking forward to 2019. I hope you are too.

Change your password!

Posted on by
1

This year saw a new form of greenmail: emails sent to you containing a password of yours stolen from a compromised site.  I saw the first one of these literally an hour or two before boarding a flight to Manchester UK to speak at the SQL Saturday there. My wife received it.

They often take a form similar to:

As you may have noticed, I sent you an email from your account.
This means that I have full access to your account: On moment of hack your account has password: Tel3phone!

You say: this is the old password!
Or: I will change my password at any time!

Yes! You’re right!
But the fact is that when you change the password, my trojan always saves a new one!

I’ve been watching you for a few months now.
The fact is that you were infected with malware through an adult site that you visited.

If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other device.
This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it.

I also have access to all your contacts and all your correspondence.

Why your antivirus did not detect malware?
Answer: My malware uses the driver, I update its signatures every 4 hours so that your antivirus is silent.

I made a video showing how you satisfy yourself in the left half of the screen, and in the right half you see the video that you watched.
With one click of the mouse, I can send this video to all your emails and contacts on social networks. I can also post access to all your e-mail correspondence and messengers that you use.

If you want to prevent this, transfer the amount of $745 to my bitcoin address (if you do not know how to do this, write to Google: “Buy Bitcoin”).

My bitcoin address (BTC Wallet) is: 19Q4HZtCznuBGcuWng7cacwqZV13gNpZas

After receiving the payment, I will delete the video and you will never hear me again.
I give you 48 hours to pay.
I have a notice reading this letter, and the timer will work when you see this letter.

Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address.
I do not make any mistakes.

If I find that you have shared this message with someone else, the video will be immediately distributed.

Best wishes!

I actually LOVE this form of greenmail because I suspect it’s highly effective.  I’m also amused because the above (edited) email came with the subject: Security Alert. You account has been hacked. Password must be need changed. It then goes on to tell you that even if you do change your password, the hacker can read it.  I’m also amused because the faux hacker’s concept of my time at the computer sounds FAR more exciting than what I actually do at the computer (and of course the fact I don’t keep my webcam plugged in!)

When confronted with a password that the user recognizes, I’m sure folks pay up.  But, don’t. Yeah, it’s probably a password of yours, but it’s almost certainly from a site that was hacked months previously and has nothing to do with your email, current account, etc.  You can easily find lists of email addresses and passwords online, especially if you’re willing to pay.

In the case of the above password (changed to be extra safe, but even if I hadn’t it most likely wouldn’t matter in this case) I know what service was hacked. Fortunately I only used that password on that one site and it had no financial data associated with it.

That said, again don’t use obvious passwords. In fact effective password systems would incorporate a list such as the one here: Worst 25 passwords of 2018. If you’re using a password on this list: SHAME on your.

The takeaway: If you haven’t, for 2019 make a New Years Resolution to use UNIQUE passwords for every site you use, use a password manager to remember them, and do NOT make them obvious or easy!

 

 

 

Merry Christmas

Posted on by
Reply

It’s Tuesday, which means normally I’d try to write something insightful about caving, or computers, or technology, or our human experience.

Instead, I can only say, “Merry Christmas” to all my fans and readers.

I was hoping to get to 2000 page views this year, looks like I’ll be about 50-100 short, but that’s ok. I’ve enjoyed writing my weekly missives and I hope you’ve enjoyed reading them.

Now get off the computer and spend time with your family!

Social Deconstruction II

Posted on by
2

In a previous post, Social Deconstruction I reflected on a barrier that had been put up on a Thursday, and by Sunday, completely bypassed. I had recent cause to revisit that area again recently and

Barrier bypassed

Barrier bypassed

as you can see, an actual, real gate has been put into the fence. The power of the crowd basically overruled the original intent of the landowner.

Of course, this could have been done from day one.

This is true in the IT world. How often has the security department come and said, “we’re implementing this new security policy” with little input from actual users and are surprised when users get frustrated and try to bypass the new security feature.  I had this happen at a client of mine. In the case of the fence above, people bypassed the security the fence builders wanted (presumably to reduce liability), and by doing so, increased their chance of getting hurt (and ironically, presumably increasing liability).

One of the security features that I think annoys most of us are passwords, or more accurately arcane password requirements. For example, some systems require a certain amount of complexity, but don’t necessarily tell you what the rules for complexity actually are! Yes, I’ve had that happen. Turns out they required special characters, but, only a specific subset of special characters and the ones I tried weren’t on that subset.

Now a minimum password length, makes sense. A one character password can be cracked by anyone. But, what about short maximum password lengths? Yes, perhaps that was a good idea when memory and storage were scarce (ok even then, not a great idea) but not so much these days. Yet, I know at least one system where your password has to be between 8 and 14 characters.

Another annoyance is the “must change every N days” where often N is something like 90 (though I’ve seen even lower). What does this mean? Folks end up with passwords like: Secur3Passwrd$1, Secur3Passwrd$2, Secur3Passwrd$3, etc.

Truth is, many of the so called password rules, actually encourage us to create lousy password, and so we repeat stuff, or write it down or take other steps that make it easier for to use them, but also as a byproduct weaken passwords.

The National Institute of Standards and Technology recently released an updated set of guidelines: NIST 800-63B that discuss good password requirements (note I have NOT read the entire document, just large portions of it).  Spycloud has a decent review here: New NIST Guidelines Acknowledge We’re Only Human. I’m not going to recap the recap here, but I will add what I generally do:

  1. I use a password manager. You can read reviews for finding one that best meets your needs. Personally, I use one that does NOT have storage on the cloud. While in theory they’re encrypted and secure, I get paranoid. (Yes, I do recognize if someone compromises my desktop, they can get access to my local password manager. But on the other hand, if they get access to my desktop, they can probably just install a keyboard logger and I’m hosed anyway.)
  2. I use a different password, automatically created by the above password manager for nearly every site of system I log into.  This ends up meeting most (but not all) of the NIST suggestions (they’re certainly NOT easy to remember, but they don’t have dictionary words, can be as long as I need, most likely are NOT in a previous breech, etc.)

Note, I said most, not all. There’s a few places I used passwords I can remember. These are systems I interact with on a daily or near daily basis, such as my desktop, AND the password manager itself. There would be no point to have a password manager if I couldn’t log into it, or if the password were so simple anyone could guess it.

So, I make sure these passwords are easy to remember, but extremely hard to guess. (For example, they do NOT include the name of my first dog, my mother’s maiden name, etc.)

In conclusion, if you’re in charge of security, make it usable, or else people WILL try to bypass it, simply to get the job done. And, remember, you’re always in charge of your own security, so make it usable, but secure.