Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
17  
Just use a password manager like KeePass, LastPass, or 1Password. This is essentially a solved problem. –  Stephen Touset 2 days ago
8  
7  
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 yesterday
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? –  Sarge Borsch yesterday
3  
@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" 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 yesterday

5 Answers 5

up vote 22 down vote accepted

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.

share|improve this answer
4  
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 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". –  Marc Schneider 2 days ago
1  
You could strengthen it a little by using really weird variable names... –  S.L. Barth 2 days ago
2  
@S.L.Barth, but then you'd be back at a standard passphrase. –  SOJPM 2 days ago
3  
@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. –  Marc Schneider 2 days ago
2  
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 and the like.) –  Mark 2 days ago

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.

share|improve this answer
1  
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 yesterday
    
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 yesterday
    
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 23 hours ago

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.

share|improve this answer
    
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 yesterday
    
@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 23 hours ago
    
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 15 hours ago

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.

share|improve this answer
    
This doesn't really answer the question. –  Mark yesterday
    
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) –  SOJPM yesterday
    
Malbolge doesn't has a predictable syntax though. @SOJPM If you would write your own program, I would assume its safe –  Tom 14 hours ago

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.

share|improve this answer
    
Why downvoted?? –  Tom 2 days ago
7  
I'm not the downvoter, but: if this catches on, scripts will be added to rainbow tables soon enough. –  S.L. Barth 2 days ago
    
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 2 days ago
    
1  
@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. –  J. C. Leitão yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.