24

Passwords with a mixture of letters, numbers, and special characters are sometimes hard to remember. Is it secure to instead use a small amount of memorable source code as a 'passphrase'?

As an example, take a simple for loop in Go: fori:=1;i<5;i++{fmt.Println(i)}

Normal people would only see the cryptic syntax, but as a person with a programming background, this may be more easy to memorize. Would it be at least as secure as a normal password?

Panzercrisis
  • 554
  • 4
  • 13
user3147268
  • 735
  • 6
  • 13
  • 22
    Just use a password manager like KeePass, LastPass, or 1Password. This is essentially a solved problem. – Stephen Touset Apr 10 '15 at 17:26
  • I currently do so for a long time but this question just made me curious. – user3147268 Apr 10 '15 at 17:36
  • 12
    NO! [Chrysanthou had no trouble cracking the SHA1 hash that corresponded to "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn1" for one simple reason. This is a fictional occult phrase from the H. P. Lovecraft short story "The Call of Cthulhu," and it was contained in this Wikipedia entry.](http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/2/) If your source is on the internet, your password is crackable! – Chloe Apr 10 '15 at 21:41
  • 8
    Depends on the programming language. Perl would be an excellent candidate as its often hard even for the person who writes it to read their code a week later! – Ernest Friedman-Hill Apr 11 '15 at 03:05
  • 3
    using Perl is basically the same as "normal" password, because any weird character sequence can be treated as perl code (at least, with some modifications), isn't it? – Display Name Apr 11 '15 at 06:33
  • @StephenTouset But you still need a password for your password manager! :P – Matthew Steeples Apr 11 '15 at 13:03
  • As I commente above to you, I use a password manager and I think it is a necessity if you want to use complex and secure passwords while managing and storing them safely ;) – user3147268 Apr 11 '15 at 14:51
  • @Chloe I think the OP meant having `fori:=1;i<5;i++{fmt.Println(i)}` as their password, because it is easy to remember and even more difficult than traditional passwords with just a few letter-number-symbol combination. – Evan Carslake Apr 11 '15 at 20:35
  • 5
    @EvanCarslake: I think Chloe meant that, now that user3147268 has posted the phrase `fori:=1;i<5;i++{fmt.Println(i)}` on the Internet, it has been added to the "dictionaries" of many password crackers — just like, despite its intrinsic entropy/strength, "[correct horse battery staple](https://xkcd.com/936)" is a bad password, because everybody knows to try it.  But Chloe misread the question, which asks, "Is it secure to use a small amount of memorable source code as a 'passphrase'?  *As **an example**, take* ..." – Scott - Слава Україні Apr 11 '15 at 22:30

6 Answers6

27

You can use source code as password.

However I'd strongly recommend against using source code as a passphrase.
The reason for this is entropy.
Passwords / passwphrases need to provide lots of entropy (100 bits+) and programming languages usually pose severe constraints on the formulation of instruction thus resulting in less entropy per character than even with a standard passphrase.

What may be possible aside of that, you can use source code files (100 lines+) with lots of complex instructions and non machine-codable as keyfile.

SEJPM
  • 9,540
  • 6
  • 37
  • 67
  • With a limited and specific character set of a programming language could this lead to less entropy. Furthermore I like the idea of using it as a key file – user3147268 Apr 10 '15 at 12:41
  • 6
    I'm not sure that it is really as bad as you think. From an information theoretic standpoint, this is nothing more than changing the alphabet of possible characters. In the example above it's approximately equivalent to an 8 character all lower case password, assuming that the attacker knows the password generation algorithm. See https://xkcd.com/936/ while this isn't as good as correct staple horse battery, it is easier to remember than Tr0ub4dor&3 yet allow you to jump through "special character hoops". – COL Wotohice Apr 10 '15 at 14:08
  • 1
    You could strengthen it a little by using really weird variable names... – S.L. Barth Apr 10 '15 at 14:35
  • While you lose entropy for a password of the same length, you are also allowing for more characters in the password for equivalent 'meatspace difficulty'. So the real question is of two passwords of equivalent 'meatspace difficulty' which is better, and I'm not sure that is clear cut. As Marc points out, correct stable horse battery seems to be better than both when measured by entropy per 'meatspace difficulty'. – Lawtonfogle Apr 10 '15 at 18:09
  • 2
    @S.L.Barth, but then you'd be back at a standard passphrase. – SEJPM Apr 10 '15 at 18:19
  • @MarcSchneider, "Tr0ub4dor&3" is a somewhat "bad" sample as you replace characters through their common analogons. A good password (hard to remember) would be something like this: "N2Oyil6b7_/$Zp2lxxs]?ZkQ" (~150 bits of entropy). And yes, one can build a secure passphrase from source code commands, but these passphrases would be significantly longer for same entropy as a standard native language passphrase, as commands are mostly highly predictable in source code like the mentioned for loop where i as variable and 0 as initial is extremely likely. – SEJPM Apr 10 '15 at 18:23
  • @SOJPM The reason I used Tr0ub4dor&3 is that is the difficult to remember password from the xkcd comic. The point I was trying to make is that requirements like "one uppercase, one lowercase, one number, and one special character with a minimum of 8 characters" are common but cause people to have difficulty remembering the password. A code snippet would meet the requirements and be easy to remember. "N2Oyil6b7_/$Zp2lxxs]?ZkQ" is difficult to remember. Given typical password requirements code is a good compromise. – COL Wotohice Apr 10 '15 at 18:30
  • 4
    @Lawtonfogle I think that you hit the nail on the head. We shouldn't be measuring passwords based only upon entropy, but rather based upon entropy and 'meatspace difficulty'. I particularly like that phrase. – COL Wotohice Apr 10 '15 at 18:35
  • @SOJPM N2Oyil6b7_/$Zp2lxxs]?ZkQ is a great password until someone looks at the stickynote on the screen with it written down. If we are talking about access to the machine in question, then that actually doesn't matter (physical access and all security is lost), but passwords to admin accounts and such would be a major risk having them written down. At my first job, I was IT for a bank, and I remember one of the higher ups have a sheet of paper with all their passwords written on it in their office. One picture and that bank would've been ruined. – Lawtonfogle Apr 10 '15 at 19:44
  • 3
    Grammatically-correct English has an entropy of around 1.5 bits per character, so to get the target entropy of 100 bits, you're looking at a 67-character passphrase. I suspect programming languages, with their stricter syntax requirements, have an even lower per-character entropy. (This is, of course, ignoring [TECO](https://en.wikipedia.org/wiki/TECO_(text_editor)#As_a_programming_language) and the like.) – Mark Apr 10 '15 at 23:51
  • Arguably, some programming languages could provide the level of entropy you'd like. Ones that are closer to human language, like CoffeeScript or Python, would work better. Still not a wise idea, but if you've gotta do it, you can definitely do it well. – Seiyria Apr 11 '15 at 03:42
  • 1
    speaking about meatspace: I've trained myself to quickly (about 20-30 minutes) memoize random-character passwords with length up to 16… the trick is to divide them into chunks of length 4, and each chunk is quite easy to remember separately. – Display Name Apr 11 '15 at 06:31
  • @Seiyria Assembler as a programming language that operates close to the hardware does have simply a lack of a wide range of special characters. In conclusion the entropy would be bad. – user3147268 Apr 11 '15 at 08:11
  • note: I've done some training myself concerning random passwords, I've learned a 32 char random password within a few days, within the same time I've learned my other 40 char random pw. learning random passwords isn't that hard if you train them a little bit (type them 10-40x and you'll have them memorized) – SEJPM Apr 11 '15 at 10:07
  • 1
    @SOJPM this will work with a few passwords but remembering a few more and you will be lost. Password managers solve this problem. Mostly you only need to memorize the passwords for your main accounts or the encrypted password database. – user3147268 Apr 12 '15 at 14:24
  • @user3147268 that's was makes password managers so nice. You only need to remember a few passwords (4 in my case: android boot, windows boot, password database and high security containers) add some keyfiles here and there and you'll be pretty safe – SEJPM Apr 12 '15 at 15:32
20

Like most password generation algorithms, this one relies on security through obscurity.

As long as nobody suspects that you use this method, nobody will use a cracking tool which tries random valid source code snippets and the rule of strength = possible_characters ^ number_of_characters will stay valid. But as soon as someone suspects that you might be using it, or when it even becomes a common method because you start advertising it as "a very good idea" on a website, this would change.

As soon as someone feels compelled to write a tailored cracking routine, you have to look at how much entropy there really is in your sourcecode. And when you are limited to "small, memorable code snippet in common programming language", you are maybe down to a few billion possible passphrases, which is not enough to withstand a serious brute-force attempt.

Philipp
  • 49,017
  • 8
  • 127
  • 158
  • 2
    Exactly. And you can never know whether your shiny new idea is independently (secretly) used by many others, and good password crackers may know much more about the psychology of choosing passwords than you do. Whatever clever trick you use, the attacker may predict it. Therefore you need to disconnect the choice entirely from anything predictable about you (i.e. use randomness). Then even if they correctly predict your decision, they can only conclude that you tend to choose random passwords. – isarandi Apr 11 '15 at 21:31
  • Not sure you're saying this is a bad idea, but as it prevents all the huge security problems of password managers I guess it's not a bad idea comparing the difficulty to remember to the 'external entropy' even if the 'internal entropy' is quite low. – David Mulder Apr 11 '15 at 23:45
  • The entropy of the attacking method can't be lower than the entropy of your generation method. Therefore having a high entropy generation method gives you peace of mind. – PyRulez Apr 12 '15 at 00:12
3

It's best to use a method that would stay secure even if everyone used it. You'll have less to worry about and it lets you collaborate with others in tweaking the method to be the most secure, because you don't have to keep your methods secret.

This "the enemy knows the system" approach is a huge motor for innovation and advancement in information security. Otherwise you'd have independent groups that each work on their own obscure, supposedly unexpected designs and principles.

Furthermore, you have no way to quantify how secure your system is because it all depends on psychology and what others know about you.

In some walks of life you need to be creative and build your strategy on some personal, unique insight that you have to keep secret, but information security is not like that.

isarandi
  • 137
  • 3
  • Indeed, ideally you would remember all random per-user unique generated password by hard, but realistically you can't. So either you make the passwords easier to remember or you store them somewhere. The second option is dangerous as it creates a very easily attackable point (e.g. a password manager, intercepting the user accessing his pass store once results in **full** identity theft), so with passwords (unlike many other things) obscurity is to some extent an important requirement. – David Mulder Apr 11 '15 at 23:50
  • 1
    @DavidMulder I thought we are already talking about the master password, since password reuse is a big no-no anyway. Anyway, my usual strategy is to *first* generate a random password and *then* memorize it by making up some poem or expression that fits it. It's quite remarkable how much pattern you can find in any random string. For example, freshly from random.org: "pYmQ3xmKMy". I could say "pYthon may queue three times more Key Managers, why?". If you do this to the first password that you generate, you lose no entropy (only if you repeatedly regenerate for easier memorization). – isarandi Apr 12 '15 at 00:28
  • If you're able to memorize tens and tens of passwords that way: my respects. If however you are only able to remember a handful and store the rest in some kind of password manager then that's a risk you are willing to take. – David Mulder Apr 12 '15 at 08:56
2

At first glance, this seems like it might be a good idea. Like many suggestions relating to passwords, in some situations it may even be an OK solution. However, when you consider it in more detail, a number of shortfalls become evident.

If I was trying to crack someones password, one of the first things I would do is try to find out as much information about the person as possible. If I know you are a programmer, then I may well take a guess that you use some code for your passphrase. I've now narrowed down the possible search space.

If I know what your preferred programming language is, I've now reduced the search space even further. I only need to consider legal forms from your preferred language.

Now when I consider the legal forms which are allowed in your preferred language, I've reduced the search space even further. If there is a known maximum character limit for the passphrase, that search space is even smaller again - in fact, for most languages, there will only be a very small set of possible legal forms which will fit in to the allowed character limits for many passwords.

As indicated by other answers, the real problem with 'clever' password/passphrase schemes is that they rely on others not being able to guess what your scheme is. As the popularity of a scheme increases, the benefit of that scheme reduces. Above all, any scheme you choose needs to be something which is not easily associated with you.

The other problem with clever password schemes is that they are rarely as clever as you think theyy are. If you analyse passwords dumped from stolen password repositories, you will be surprised how 'common' many of these clever schemes are. You may also be surprised how often the clever scheme is related to the domain the passwords came from. For example, I saw passwords stolen from an Air Force system and guess what, the vast majority of passwords were either derivations of various aircraft names and model numbers or character names from movies or books with a military or air force theme. Likewise, passwords dumped a couple of years ago from a christian dating sight had large numbers of passwords which included phrases, chapter and verse numbers from the bible. If I was going to try and crack github passwords, I would almost certainly look at code as a possible pattern.

The one minor benefit of using code is that you will likely have a longer password/passphrase, which is often as important or more important as the underlying complexity. Too often, people use short passwords because they are easy and quick to type. These days, I think most people are far better off ensuring that they use either 2 factor authentication or 2 step authentication whenever possible and use a password manager which will generate random passwords for you and in most cases, eliminate your need to remember them.

Tim X
  • 3,252
  • 14
  • 13
-2

Use Malbolge. After all that's essentially random, right?

(=<`#9]~6ZY32Vx/4Rs+0No-&Jk)"Fh}|Bcy?`=*z]Kw%oG4UUS0/@-ejc(:'8dc

That's the hello world program.

Lucas
  • 105
  • This doesn't really answer the question. – Mark Apr 11 '15 at 21:13
  • as there are very few programs in malbolge and they are all publicly known this would be a very bad choice. First you wouldn't have much entropy (not many programs, as soon as the source gets known). Second, the point of the question was to use easy-memorizable source code, but malbolge code can be memorized as easy as a standard random password, making it essentially an inferior choice. (due to the low entropy) – SEJPM Apr 11 '15 at 21:15
  • Malbolge doesn't has a predictable syntax though. @SOJPM If you would write your own program, I would assume its safe – Tom Apr 12 '15 at 09:52
-3

This is actually a very good idea. You won't find this kind of passwords easely in rainbowtables, and most bruteforce attacks don't include characters like this or search for such long passwords.

Its only weakness is the fact that it is a short code (not a short password), if someone knows you have a script as password it could be easy for them to guess. This is assumed by above answer by SOJPM.

Tom
  • 67
  • 5
  • Why downvoted?? – Tom Apr 10 '15 at 12:52
  • 8
    I'm not the downvoter, but: if this catches on, scripts will be added to rainbow tables soon enough. – S.L. Barth Apr 10 '15 at 14:45
  • If people globally know that you're using programming languages as password, it is of course not that safe anymore. You could prevent this by putting a password in the code but then we're back to square one. – Tom Apr 10 '15 at 15:52
  • http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking – Chloe Apr 10 '15 at 21:44
  • @Chloe I can't find a part that says my assumption is wrong? – Tom Apr 10 '15 at 21:50
  • 2
    @Tom, your assumption is that preposition A: "it is a good password because few people use it" will not lead to preposition B: "because it is a good password, many people will use it". IMO that assumption is not often the valid. – Jorge Leitao Apr 11 '15 at 00:28