Saturday, 30 September 2017

Memory Fault

Whether it is my original system-generated username from Prodigy in middle school (MMFD70D), my dad’s license plate from when I was in elementary school (LDV-34G), or completely seemingly-useless bits of details like the manufacturer of the urinals at the office (Sloan), my brain just tends to soak it all up.

Over the years, people have praised my ability to remember things…

Sometimes I feels like quite a blessing. But I feel like it is also a bit of a curse.

Because I could rely on my memory, I didn’t really have to apply myself in school. As long as I could remember enough concepts and terminology, I could squeak by without really having to put in much effort.

Looking back, I regret taking that path of least resistance.

Don’t get me wrong… I definitely appreciate having it as one more tool at my disposal. Thanks to my memory, I can keep track of a lot more moving pieces during projects than most folks, which is a huge boon for my productivity and efficiency.

It just might have been nice if I hadn’t been able to use it as a crutch while I was in school… Still, though… Can’t change the past… And even if I didn’t put in all of my effort into education early on, who’s to say I would be in a better position at this point in my life if I had? I have an awesome wife, an adorable daughter, and things are good. Maybe I need to remember that more…

Saturday, 5 August 2017

Pwned Password Protection

Back in September of last year, I wrote a little about Special Publication 800-63 that NIST had drafted (which was later finalized and released in early 2017).

One of aspect of the recommendations that I think a lot of services/companies struggled with related to preventing the usage of credentials that had previously been in a breach, leak, or other sort of compromise.

It seems like that would be very difficult to do well, without having someone at your company spending a bunch of time on the darknet markets, downloading the latest leaks. And then what do you do with the data once you have it? Even if it’s only stored internally and accessed behind-the-scenes, having that sort of information lying around just seems a bit risky (and that’s coming from someone with a VERY high risk tolerance!)

Thankfully, Troy Hunt saves the day. He already has done the hard work of collecting the data, anyhow. Not only does he already have an insanely-large stockpile of leaked credentials, but he now SAFELY exposes those password hashes so the rest of us can benefit from his work.

There are no usernames, email addresses, or other identifiable information. It’s just a list of SHA1-hashed passwords. The thinking goes that even if a specific email address and password combination wasn’t part of the credentials that were leaked, if anyone else used that same password and had their credentials compromised, that password should be considered ‘no good’ and shouldn’t be used.

That may be a bit overkill for some sites, but especially for sensitive information (such as medical or financial data), it’s probably worth being a little overly-paranoid…

Anyhow, he has RESTful API that lets you send over individual passwords (SHA1-hashed or, if you are feeling way too trusting, in plaintext) and you’ll know whether or not the password is in his list. Personally, though, take the storage hit and download the whole database, so you can do offline processing.

I’m still not sure how I’d utilize this… since it could easily generate a visceral knee-jerk reaction from some users… who might not understand the password may have been from a compromise unrelated to them and that it wasn’t a compromise of the current system they are using… It might be worth waiting to see what sort of traction it gets in the private sector and what sorts of UX conventions get used by the more mainstream sites. Either way, though, it definitely is helping things head in the right direction.

Sunday, 16 July 2017

Investing In Yourself

As I’ve touched upon in earlier blog posts, I’m a big fan of working on skills that allow you to ‘level up’ as a developer. It is also something I typically struggle with, so maybe that’s why I keep coming back to it…

For much of my life, I’ve been lucky when it comes to computers… Even from an early age, it all just sort of ‘clicked’ for me. I loved being able to create things and the idea that if I told the computer what to do — in just the right way — it would do it. It became addictive. I would obsessively work on a program until I could finally get it to work. In middle school, I even wrote programs that would solve my math homework (generally with a brute force approach because ‘n00b’).

Anyhow, I think it’s partly because of that early luck I had… and figuring out I could be good with computers without putting in much effort… that I never really dedicated myself to really trying very hard. If something I wanted to learn (like assembly or C) because too difficult, I’d just give up and find a way to accomplish what I wanted a different way. As a general rule, that’s a horrible attitude to have… but it also was somewhat beneficial in a way, too. Even later in life, if something seems a bit too much effort, my first impulse is generally to see if someone else has already solved the issue, if there’s a NuGet package that does what I want, if there’s an open source library for it, etc. Other developers I know seem to use every opportunity they get as an excuse to re-invent (re-implement?) the wheel. I mean, I guess it’s good if you are capable of making your own file system, internet protocol, or whatever… but with very few exceptions, I can’t think of any reason why a business would want you to…

So I guess there are different extremes…

I am aiming for a middle-of-the-road approach… I just want to keep my skills up-to-date, be aware of market/industry trends, and get at least a little experience (whether through my employer or on the side) with newer technologies and frameworks so I can more effectively do what I’m good at — solving problems.

Sunday, 25 June 2017

Imposter Syndrome

One really annoying side-effect of networking with other developers, learning about technologies used at other companies, and reading development books is it seems to skew how I view my own skill level.

According to Wikipedia:

Impostor syndrome (also known as impostor phenomenon or fraud syndrome or the impostor experience) is a concept describing high-achieving individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

Generally speaking, the people I interact with in the I.T. field all seem to view me as a highly-capable developer. We might have our disagreements here or there on technology choice, a specific implementation, or that sort of thing… but I think overall I’d get pretty high rankings from my peers (whether professionally or just friends in the field).

And, looking back at other developers I’ve worked with over the years, many of them — even highly-paid consultants — would be stumped by things that seemed almost childishly simple to me.

Even so, sometimes it’s very difficult to shake the feeling that I’m far less skilled than I should be. But I suppose that’s better than the alternative — unwarranted overconfidence.

Saturday, 20 May 2017

Be The Worst

In any group, most people strive to be the leader, the alpha, the center of attention. From a professional standpoint, though… F’ that. Be the worst. I want to surround myself with people far more skilled than myself. I can get so much more out of that. And generally it inspires me to rise above the people I’m with or, at the very least, to play off of their skills with my own. The end result can be pretty awesome.

Sadly, life happens… You don’t always get to work with the folks you want. Many of my old development friends now live far away and are busy with their own jobs, family, etc. But I still think it’s a good goal to have…

Maybe I’ll look for some open source projects in languages I’m not very good with. Seems like an easy way to find people more skilled than myself…