Intentional Deception

On the club application form I created, there’s a place for you to put down a password so I don’t end up having to send a randomly generated “2foas2!v” to a million people. Being counterculture and all that, I don’t like passwords. Nobody does. I tried googling for an alternative way to identify yourself  or perhaps, I could come up with an alternative myself1. But in the end, I just went with a normal password + salted hash.

Alright, well, underneath the place where you put your password, I write down “Your password is stored as a 512-bit hash. We do not know what you type”. I have to do this because, well, who would trust me with their password? It’s just too easy to harvest giant lists of email passwords. But still, including this bit is a bit troubling. Technically, it’s not untrue. The script is configured to create a salted hash and it throws out the original password so that it is cryptographically impossible for anyone to crack it within a few thousand years. But wait, what if Mr. curious-white-knight-hacker looks at the form submission and sees... woah! the password is sent as plain text. If you’re on public wifi, anybody can steal your password given the opportunity. Although the password is secure on the server, it’s wide open in-transit. So what’s the deal here? My intention is to get the user to trust me with his password, since I genuinely can’t see it. But of course, I still acknowledge that this sentence sort of gives a false sense of security. But it’s not like the FBI wants to know your club website password2. Still, it begs the question: does this constitute lying? While the words are true, the statement clearly is deception. To the user, the sentence I typed looks like “Your password is secure”. He doesn’t know what the rest of the bit-hash junk means, so he picks out a few key words and misunderstands what it’s really saying. Would it be better to leave out the sentence completely? Sure! Let the user completely forget that using the same password for your GMail and isn’t a good idea!

I wonder if big companies hire people to ponder these moral dilemmas. That would certainly save a lot of time for the programmers. Of course, you could be like Facebook and just tell your employees to ignore their ethical concerns.

Ha, joking. Please I’m joking.

"The sunlight is so bright, it's burning my rectums!"  "...uhh"

  1. I thought about having, like a 3x3 setup of 9 buttons. Instead of a password, you would press the 9 buttons in any order, and that would be your password. It’s even funner on touch devices (stolen from Android). Well, there are 9! = 362880 combinations, which is far more than enough security for a club website with a single point of entry. But even this button nonsense is a mess to remember, and whoever’s standing behind your shoulder sees what you’re doing. What about a large coordinate system? Like, you would see a 30x25 grid, and you would choose a point from the 30x25=750 combinations. Security-wise, it’s sufficient, but it’s not very intuitive. If I ever need a high-security lock for myself, I would setup a program that would generate scripts, but these scripts would have a single security vulnerability inside them. To open the lock, you have to enter parameters that exploit the vulnerability and compromise the system. Ha, or a normal keypad would do, but that’s just like a password. So for this form, I just went for a simple password, and no requirements or any of that (who’s to blame for starting this trend of password complexity requirements?).  So really, you could have a password with just one character, like the symbol “!”. Of course, let me tell you how miraculously secure this is: Say, if you limit failed password attempts globally, per account to 10 per hour, a hacker would have a tough time just figuring out where to start! You’d have to be insane to think about brute forcing 10 passwords per hour. Of course, you could be a dick and just lock out people’s accounts, but to get the password, brute forcing your way to the symbol “!” would take at least 2 hours (3 full resets), possibly less if you’re lucky with guessing. ↩︎
  2. The alternative would be to have some kind of local hashing, or possibly SSL. ↩︎

Post a Comment

Fri, 21 Jun 2024 17:03:47 GMT