23

Passwords have been a problem since the dawn of computing. They tend to be either so complex that no one can remember them, or so obvious that anyone could guess them.

...

Some users choose to write their passwords down on paper and keep them in their desk drawers or (even worse) stick the paper to their computer screens. - ComputerWeekly

Assuming that I'm a doors manufacturer trying to avoid passcode-based door locking systems.

What other authentication techniques are there that are quicker / easier than passcodes, but don't reduce security?

What are pros and cons of each one?

storm
  • 1,714
  • 4
  • 16
  • 25
  • 2
    Folks, this is why we try to narrow the scope of questions. Securing the authentication of a web service is radically different from securing physical access. It's always important that we are all on the same page, especially when people can use terms that are ambiguous. – schroeder May 02 '16 at 17:06
  • 5
    There is no need to compromise between usability and security. Just hire guards for the door. – emory May 02 '16 at 18:10
  • 20
    @emory Guards also have their security vulnerabilities. They are both vulnerable to brute-force attacks (*literal* ones, as in being stronger and better armed) and more subtile exploits (like extortion or bribery). – Philipp May 02 '16 at 18:19
  • 12
    Keys have been used for that purpose for hundreds of years. – kasperd May 02 '16 at 22:15
  • Authentication by combat. Place a guard at the door and an array of weapons. You may wish to implement this using an immortal guard. Authentication by riddle. Place a sphinx at the door, and have it pose a question to the challenger. – Aron May 04 '16 at 09:26
  • @Philipp [guards](https://www.youtube.com/watch?v=OdKa9bXVinE) have other failings! – Dave May 05 '16 at 21:31

4 Answers4

33

As a general rule to remember: Don't make it to hard to use! If it's to hard to use and you keep forgetting, all you've done is shown that you need a different security method to make your door usable.

Things mentioned in this post:

  • Private/Public authentication (keys)
  • UUID pre-authentication (fobs)
  • MFA(specifically 2, fob and code gen)

Things mentioned in the do not use section:

  • Biometry
  • Security Guards alone
  • Cameras(security theater)
  • Security Through Obscurity (Handshakes/patterns)
  • Roll Your Own Security

Well, with a door there's always physical security like keys to look at.

A lock is a private/public system where a physical public key is used to access the internal private mechanism (tumbler). When a user inserts a copy of the public key, they can gain access to the door and can modify its internal states (including unlocking, and locking it themporarily). This can be enhanced further by a timeout that causes the lock to lock itself, preventing follower.

Pros

  • Faster (put in place, turn)
  • Easier (one action)
  • Almost as secure as passwords (replication based on sight)
  • User Pre-Approval (only a copy of the public key gains access, so you control in advance who gets it)
  • Strong to interception (someone would have to run a pretty strong grab attack to gain access)
  • Widely accepted and used (most people are already used to the system)

Cons

  • Bad users replicating keys and leaving them around (only an issue if someone can find the lock it goes too, but worth mentioning)
  • Bad users giving copies of the key to other people who aren't supposed to have access
  • Bad locksmiths who keep copies of the keys for nefarious reasons
  • Loss prevention (he who has the key, has the power)

As you can see above, unless you run into some bad user/system adminlock smith situations you should be fairly safe as long as you make sure your ciphertumbler is safe against the usual brute forcebump key/tamper (lock pick) tactics that exist out there and is installed with long screws and a strong door frame.

Okay, let's say you want to completely do away with passwords. Now you can do something called a universally unique identifier (UUID) with pre-registration to the lock.

For this you generate a long, hard-to-guess string that gets stored on a device that gets registered with the system in advance. If that generated thing was always registered in advance you can easily change it and try to restore it before you put it on the device to give to the user. Now if the user wants access, they just put the device up against a reader, which confirms the string with your security system, and they gain access!

Pros

  • Faster(put against square, wait for light)
  • Easier(one action)
  • More secure than passwords
  • Ease of use(just put it on a small square, and you're in)
  • Pre-registration means easy tracking
  • UUID is so unique it can register every atom in the universe(good luck running out)
  • Impossible to replicate without already knowing the string

Cons

  • Bad system users (users with access to the codes internally could cause issues, scripts are you friend)
  • Loss prevention (whoever has the fob, has the power)
  • LOSS PREVENTION

Really this system is as secure as a key, but gives the extra advantage of unique "fingerprints" for the device they use to enter the building, meaning you can easily track who comes and who goes with what key.

That loss-prevention con is a big one though, as then the person needs to come back, prove they are who they say they are, and you need to invalidate the old key, flag it to watch for someone who stole/found it and tries to gain bad access, and give them a new one with the hopes it won't happen too often.

If a key is something that is easily captured or replicated in the part of town your door is going to be installed in, or your users are REALLY bad about loss prevention, you could instead look at pinned unique identifiers like magnetic key fobs and a time-based password delivered over text message or through a special device, which is called 2-Factor Authentication

Using this technique, a user is given/makes a password to the security/lock system which is stored in a key fob. Then they register their phone with a service that will generate the other password they need to enter for them upon their request. Now when a user wants to gain access, they present their key fob and enter their password from their phone into the keypad. This provides extra security from bump keys and locksmiths because you can tie a security system into it and analyze who tried to gain illicit access in an incorrect manner so you can lock out their credentials and they have to come and get new ones at security.

Pros

  • MUCH stronger security than passwords
  • VERY strong(the password can be good for as little as a minute if you decide to set it up that way
  • Extra security techniques (you can instantiate rate limiting, lockouts, and credential rollover)
  • Pre approval baked in (they have to register with you to even make their fob active)
  • You can know the exact time frame someone logs inunlocks the door based off of the password that got confirmed (once confirmed, write and entry in your security logs)
  • Uniqueness (each fob stores something from the user, and each text is based purely on the pre-authenticated phone number which allows for limitless unique entries in your security system)

Cons

  • Loss prevention (if someone loses their phone/fob you have to reissue a whole new credential for that part of entry)
  • Ease of Use (you always have to have these present. If you forget one you have to go get it)

Wow, that's a short list of cons with a long list of pros! Heck it even gives you remote security abilities!

It's a little hard to implement though since there are a lot of systems that would have to be put in place, but that's not really a con and more of a setup cost.

The "do not use" section

Biometry is a cool idea, but horrible in practice. This is like fobs, but accuracy can't be guaranteed here, and it can be thwarted with something as simple as silly putty. People also change over time. It's just a bad in practice.

Security Guards when used alone is also a don't-use this protocol. They can be overpowered, bribed, subverted, and have biological needs that may cause holes in your security during unknown times.

Cameras provide NO SECURITY on their own. They're really more of an addition to security, and can't actually stop something. It's akin to a Security Theater. Sure you could watch it all you want, but really all you're doing is fooling yourself into thinking it's secure. Someone can still break in if a camera is there, and it's really easy to hide from.

HandshakesSecurity through Obscurity is another bad case of security theater. If I have to knock twice, say a phrase, knock again, and then turn turn the key why would I ever use this system? I'd look like an idiot, and someone can just replicate the steps. You gain no more security here than you do with a key, and it's harder to use.

Making Your Own Security Protocol/System should be avoided at ALL costs unless you're doing it for research and testing purposes and let EVERYONE bang on it to confirm just how smart you are (or bring you crashing to reality on how bad your idea was). Until it's proven as safe, it's nothing more than a really bad play in the Security Theater showing.

Robert Mennell
  • 6,968
  • 1
  • 13
  • 38
  • 4
    Physical key locks have poor implementation vulnerablities. Many (most?) locks widely used today are still vulnerable to key bumping, which is much easier than traditional lock-picking, which is also a significant vulnerability. I would say somehow that belongs in the "Cons" section. Most door locks merely serve to make one's home less of a target than the next home - they don't usually actually keep anyone out who really wants in. – Todd Wilcox May 02 '16 at 18:39
  • I did note that by saying your lock is bump key resistant (which means strong springs, ussually strong enough to prevent lock picking if they prevent bump keying), but I could be clearer. You're right. – Robert Mennell May 02 '16 at 18:42
  • ... Well it seems I've written an article on this now... and I still have things I want to put in there... – Robert Mennell May 02 '16 at 19:05
  • How to crack fingerprint-controlled credit card info (like on iPhone). Step 1: Get some tape. Step 2: "High-five" the person with the tape. Step 3: Process the tape into a raised fingerprint. – noɥʇʎԀʎzɐɹƆ May 02 '16 at 20:39
  • 1
    UUID is still subject to bad actors in the factory or the keying process. While you provide great information, I don't think it addresses the point of "quicker/easier" all that well. – Jesse K May 02 '16 at 20:47
  • It should also be noted that biometrics adds the incentive for a potential attacker to attack the owner of the biometry. Namely if an attacker really needs your fingerprint and wants access, there are plenty of ways for them to get your fingerprint. – Nate Diamond May 03 '16 at 00:31
  • 2
    This answer is amazingly informative and entertaining, +100 if I could :D – cat May 03 '16 at 00:35
  • 1
    Strong springs does not prevent lock picking. What prevents lock picking is milling accuracy since lock picking depends on tolerance defects. But perfectly milled locks can't be used with keys made from metal that easily wear down because once the metal is worn the lock will no longer open (no tolerance). Therefore the best pick-proof locks are made from titanium and are super expensive. They're usually used to enable/disable nuclear missiles. – slebetman May 03 '16 at 03:41
  • 5
    Somewhere in between bare UUID and two factor is the combination UUID + short pin code. It requires some secret (the pin code) and something owned (card); while preventing the issue of people storing their access cards in their phone cases. That is actually the most common situation in modern buildings where security is important, but not critical. – Davidmh May 03 '16 at 08:11
  • 1
    I wouldn't compare door locks and keys to public key cryptography. If anything, I like to use the metaphor of *padlock and key* for public key cryptography. Ordinary (non-auto-locking) door locks is more similar to symmetric cryptography because the same key is (traditionally) needed for both locking and unlocking. Padlocks: Alice puts secret in box, puts padlock on box, Bob gets box and uses key to unlock padlock. Doors: Alice puts a secret inside, uses her key to lock the door, and Bob uses his identical key to unlock the door to gain access to the secret. Both are valid, but different. – user May 03 '16 at 09:58
  • You can have auto locking doors with key locks. Also uuid with pin is mfa, hence why I didn't put it in there. – Robert Mennell May 03 '16 at 12:12
  • @slebetman Somewhat of a step up from the [previous solution](http://news.bbc.co.uk/2/hi/7097101.stm) of securing nuclear missiles. – Voo May 03 '16 at 13:19
  • @RobertMennell Yes, you can have auto-locking doors with key locks. I did where I lived in the early 1990s. However, I don't think I have ever come across that since. Except in padlocks, of course, where it is a common feature and where manual locking is the exception. I'm not saying automatically locking door locks *don't exist*, but rather that if you are going to use a metaphor, it makes sense to use one that more people are likely to intuitively understand. Abstractions are leaky, but that's no reason to drop a bucket of water on the floor. – user May 03 '16 at 20:29
  • @MichaelKjörling That's a surprise. I've seen more auto door locks than auto padlocks(in fact around here auto padlocks are a rarity. I've seen 2 in the past 5 years) – Robert Mennell May 03 '16 at 20:32
  • @RobertMennell Might it be a geographical difference? (My reference is mostly western Europe, living in Sweden but having travelled some.) – user May 03 '16 at 20:32
  • @MichaelKjörling More than likely. I live in the USA(West coast), and let's face it the security here is pretty... ugh. – Robert Mennell May 03 '16 at 20:34
  • 1
    Pure UUID would be subject to replay attack. – Aron May 04 '16 at 09:23
  • Granted at that point it's the same as a copied physical key, so yeah... – Robert Mennell May 04 '16 at 19:15
1

Biometry is an option. A sensor identifies a physical attribute of your body like your face, your voice or your fingerprint.

Pros:

  • Your physical attributes are something you always have with you and can not forget

Cons:

  • Physical attributes actually can change over the course of your life, both slowly through natural aging or quickly in case of an accident or a medical condition.
  • Most of your physical features aren't secret, which opens up the possibility of attacks using props which mimic your appearance. Changing your physical characteristics once compromised is often impossible or very unpleasant.
  • Systems commercially available today still have rates of false-positives and false-negatives which aren't acceptable for high-security systems
  • Rubber-hose cryptanalysis becomes bone-saw cryptanalysis which is even less pleasant for you.
Philipp
  • 48,867
  • 8
  • 127
  • 157
  • 5
    That last con is horrible XD – Robert Mennell May 02 '16 at 16:34
  • 2
    Biometrics have two main problems when applied to security: the human body wasn't designed to guard bits of it as "secret", so biometric data can be read and presumably duplicated. And once compromised, they can't be changed. The rest of your cons are less important or have workarounds - if my registered finger is lost in an accident, or my image changes with age or a stroke, I can go re-register my current biometrics with the security team. – John Deters May 02 '16 at 19:18
1

Ideally you would use 2FA where one factor is something physical that you must possess, and the other factor is something that is stored in your head and cannot easily be lost or stolen. Door codes are great for this if they are short and easy to remember, and also used in conjunction with another form of authentication such as a physical key fob. Imagine the following "smart door" that allows for both short and long codes, where the short code is just 2-4 digits long.

The smart door would have the following parts:

A Keypad for manual codes, a fob, and the ability to change settings remotely

You should have the following options:

  1. You can choose to allow entry with just the fob, or the fob and a code, or just a code. The fob should work from at least a few feet away so that when you are entering in the code you can leave the fob in your pocket.
  2. You can choose to allow different settings for different times of the day. E.g. you might allow just the fob during normal hours, and require both the fob and a short code during off hours.
  3. You may choose to have a long code which can be entered without the fob, in case you lose it.
  4. You should be able to receive alerts when someone attempts a code without the fob. This protects against the case where someone watches you enter in the code and doesn't realize you had a fob in your pocket, they may later attempt to gain access by repeating your code. The alert should also tell you if the code was correct, so you know if you need to change yours.
  5. You should be able to receive an alert when an incorrect code is entered with the fob. Assuming you lost it, hurry up and go get your fob back!
  6. You should be able to remotely change certain settings. E.g. if you lose the fob, you may wish to disable the fob altogether until you find or replace it.
  7. All fobs should be configurable so there can be different settings for each fob. E.g. one fob may require a code whereas another may not. All fobs should be able to have their own corresponding codes.
  8. You should have the option to create a lockout policy after X invalid attempts.

BTW, this is pretty much how ATM cards work, but Fobs are more expensive and more difficult to clone.

TTT
  • 9,122
  • 4
  • 19
  • 31
0

Generally speaking, this is a question of authentication: How do I know who you are, and how can you prove it to me?

Within that, the answers fall into a few categories:

  • Something you have
  • Something you know
  • Something you are

There are many different ways to take apart these categories. For example, "something you have" could be a 2FA token, a smart card (with embedded certificate), or a decryption device, like a one time pad or code book. "Something you know" could be a password/passphrase, or the answers to security questions. "Something you are" would generally fall under biometrics, things like fingerprint, voiceprint, facial recognition, etc.

All of these can be defeated. For example, "something you have" can be stolen, "something you know" can be taken via force or legal action, and "something you are" can be taken from you via violence. Generally these authentication methods can all be spoofed in some way as well.

The question you specifically asked is "What other authentication techniques are there that are quicker / easier than passwords, but don't reduce security?" Quicker/easier is almost always going to point you to biometrics. They require no new equipment for the end user (no need to distribute keys) and relatively little concern about loss/theft. There is no fumbling in pockets to look for keys, no worries about giving a key to the neighbor to watch your cat, etc. There is also non-repudiation for access, meaning you can (more or less) identify who came in and when. In terms of the speed of authentication, I suppose that would be depend on whether it was local or remote.

There are three major cons that I'm aware of:

Obviously the final evaluation of the security of the product depends on the implementation of many details, but I hope this helps as a way to get started.

Jesse K
  • 1,068
  • 6
  • 13
  • Fingerprint scanning is *HORRIBLE*! They've raised fingerprints from stuff people have touched and used it to crack an iPhone. – noɥʇʎԀʎzɐɹƆ May 02 '16 at 20:41
  • I don't believe I recommended fingerprint scanning. I just said it's quicker and easier, but mentioned the drawbacks. Ease of spoofing fingerprints isn't terribly different from the ease of taking a picture of someone else's keys, which is pretty effective in reproducing standard (i.e. not designed as high security) keys. You can also easily shoulder-surf many PIN pads or at a minimum reduce the brute force effort by getting fingerprints from the used keys. If security were easy, everyone would do it right. – Jesse K May 02 '16 at 20:54
  • Maybe we should work on the other half of the problem instead. Or we could turn the conditions around so that you need not have, know or be the secret - it is stored outside 'you' and you are merely a sort of key or confirmation of it. There are ways to create codes where the 'part' that you have cannot reveal the other part, even in principle. –  May 03 '16 at 02:11