website source; use git clone git:// to clone this repository. (10062B)

      1 -----BEGIN PGP SIGNED MESSAGE-----
      2 Hash: SHA256
      4 are passwords the right solution?
      6 [I have lacked motivation to write anything lately, but this week marks the beginning of my spring college semester, so I figured I'd force myself back into a schedule.]
      8 a month or two ago I read [an article by Alec Muffett](, where he attempted to defend password authentication as possibly the only viable online security solution. I even sent him an E-mail asking him to reconsider some of his thoughts toward passwords:
     10 > [...] I came across your opinion
     11 > on password use [4] and I have to disagree with you. My issue with
     12 > passwords (as they are currently widely implemented) is that the
     13 > password has to be sent to the server verbatim, and it is up to the
     14 > server to safely handle this password (hashing it and making sure memory
     15 > where passwords are handled is promptly cleared, in case of
     16 > vulnerabilities in the server that allow reading memory), and it is up
     17 > to both the user and the server to initiate a secure connection so that
     18 > password eavesdropping is infeasible. I favour PKI, challenge
     19 > authentication, and other mechanisms which do not require any
     20 > transmission of a private key or passphrase over plaintext to the
     21 > server. This places the burden of security on the user and on the
     22 > PKI/challenge protocol itself, which I believe to be much safer than
     23 > having to place the burden on all of the user, server, and transmission
     24 > medium. Please consider these points and perhaps revise your decision on
     25 > claiming that passwords as they are used today are a sound security
     26 > mechanism.
     28 so already, that explains half my stance on passwords off the bat. I do favour PKI -- I use elliptic curve keys for all SSH connections and disable password authentication, and I would use similar authentication for websites if it was an option. to me, it makes more sense to have a file or files tied to each device I own, and should that device be compromised, I can simply log in from another device and revoke the now-insecure key. this allows for finer-grained access control than I would have with passwords: for example, right now I would have to reset my password if I logged in even once on an untrusted public computer. granted, I would have to use a temporary key for a public computer, stored on something such as a USB drive, but at least I wouldn't have to change the key on each device I own. it's a different story if you have a remarkable memory and can memorise random passwords with ease, but a lot of people including myself cannot or will not trust our memory to this task.
     30 I have more faith in <abbr title="two-factor authentication">TFA</abbr> than I do in plain passwords. to save myself from reiterating ideas I have already typed (again) I will cite my response to the [Hidden Answers question <q>What and how much credentials do you save in KeePassX?</q>](http://answerstedhctbek.onion/227514) (please note this link is only accessible over Tor or this [I2P link](http://hiddenanswers.i2p/227514)):
     32 > [W]e should look more into TFA. KeePass supports it to some extent (it combines a password, something you know - with a keyfile, something you have like a USB drive). It allows you a little more time to react to breached security because even if the attacker has one piece of the TFA, it will take him some time to get the other piece and actually be able to utilise that information.
     33 >
     34 > Weigh the differences:
     35 >
     36 > * Store the passwords in your head. **Pros:** you can't hack a brain (as far as I know). **Cons:** unless you have impeccable memory, you will likely formulate smaller, weaker passwords because that's all you can remember. Also, you may choose to reuse passwords more often, which is also unsafe.
     37 > * Store the passwords on paper. **Pros:** you can't hack a piece of paper. Also, if you don't label the passwords (you use something like you can be a little safer in case you lose it / someone sees it. **Cons:** someone can easily steal that piece of paper, and even if you use the PasswordCard, you have significantly narrowed the possible passwords for the attacker. So, if you lose that card, you're going to want to rush to change all your passwords.
     38 > * Store the passwords in a password manager. **Pros:** Password managers organise your passwords and they require you to only know the master password, leaving you with less to remember. Good managers can also generate strong random passwords for you. **Cons:** once someone gets the master password, your passwords are all in the open and you're in big trouble unless you set up TFA for all your accounts.
     40 TFA/multi-factor authentication is a definite improvement over single-factor authentication, and only recently have I decided to add TFA to any account I could find an option to do so. I also use a combination of storing frequently-used passwords in my head and storing the rest in a password manager, which are encrypted and synchronised to Google Drive and, in effect, to my phone. that way, I have a copy wherever I go and I am as secure as possible within the confines of password management.
     42 I still believe authentication should be given more thought; there are still *plenty* of organisations that have very poor regard for security and impose artificial limits on passwords out of cost/laziness:
     44 * limits on password length or character composition,
     45 * storing passwords in the remote database as plaintext,
     46 * sending back a password over an insecure channel as <q>confirmation</q> of a password reset, and
     47 * requiring a user to add <q>security questions</q> to one's account (which is a huge fucking oxymoron; there's nothing secure about security questions).
     49 if all websites agreed that these are poor practices, that would eliminate many of the issues with passwords right away. combine that with mandatory use of a secure channel such as TLS (which many sites thankfully do now), use of server-side password hashing such as bcrypt or Argon2, and user education on proper password formulation (no password reuse, no dictionary words, et cetera) and sites would be sitting pretty while not compromising compatibility with the current security ecosystem. users should know that password managers are as necessary as an Internet browser at this point, and that there are many user-friendly solutions to this already: many Web browsers even have built-in password saving and synchronisation across devices, but of course there are also solutions such as KeePass and LastPass. in fact, these points I just made are in line with Alec's article I linked at the beginning, so we're in agreement there.
     51 but what if we want to take a step further and opt for a more secure (but less orthodox) solution? let's look at the list of advantages Alec gave favouring passwords, and compare this to something like PKI:
     53 1. passwords are easy to deploy *[and so is a PKI solution, at the cost of a temporary stage of switching from passwords to PKI. if done correctly, PKI can be abstracted to the end-user so that it is actually easier to use than passwords, and users can just click <q>generate login</q> to create a random file and save it to an internal (optionally synched) database on-the-fly.]*
     54 2. passwords are easy to manage *[... see above for why PKI would be easy to manage without the user being concerned with implementation.]*
     55 3. passwords don’t require identity linkage between silos – so your Google username can be different from your Skype username, can be different from your username *[... PKI doesn't require this either; simply generate new keys for each site you use.]*
     56 4. passwords are scalable – you can use as many different ones as you like *[... same for PKI.]*
     57 5. passwords can be varied between silos so that loss of one does not impact the others *[... see above.]*
     58 6. passwords don’t (necessarily) expire *[... still same for PKI. advanced users could optionally be allowed to set expiries for keys (just like X.509 allows), and users could at any time revoke a key from a website if it's compromised.]*
     59 7. passwords are the purest form of authentication via ‘something you know’, and thus ideal for the network or “cyber” environment. *[now, this **is** an actual argument for passwords. PKI is along the lines of <q>something you have</q>, but for the majority of security-conscious users, so are passwords. passwords are stored in a database or on a piece of paper (something we have) unless we have remarkable memory (more power to you) or we reuse passwords (which is wrong).]*
     60 8. you don’t need to pay an intermediary or third-party a surcharge just to get a new password, nor to maintain an old one *[... same for PKI.]*
     62 aside from the fact that PKI is <q>something you have</q> rather than <q>something you know</q>, it maintains many of the properties of passwords and has the added benefit of being secure by default: secret keys are not transmitted over the wire, and server database compromises would be fruitless since all keys stored are already public. end result, both users and server administrators have less to think about and worry about. there are still perfectly valid uses for passwords, but I would like for people not to fool themselves into thinking passwords are the universal solution. passwords should *strictly* be something you know rather than something you stick in a database, and you should only have to memorise a handful of passwords, instead of having to remember one password per mail account, social network account, bank account, forum account, game account, and whatever other accounts you have. passwords should be used in a local context: useful to decrypt your PKI database locally or to unlock your computer/phone quickly.
     64 Tags: security
     65 -----BEGIN PGP SIGNATURE-----
     68 9k0/AQD6LFCnaZoJXmdDahnY1o2jDTlbXec2JZzzYvUwLjOJFQD8C3jJDW5HtWya
     69 CptytTk0/rV66tODD0s9zWb0nAoSvwI=
     70 =IiJh
     71 -----END PGP SIGNATURE-----