-1

I have been tasked with writing a random password generator to be used on a series of throw away accounts.

In this scenario, the accounts need to be very secure and will be deleted after a single day and replaced with another username/password combination.

I have a master array of 70 characters. When a new password is created, 17 random characters from the array are selected, displayed on screen to the user and are never saved/recorded anywhere.

Making the assumption that the password is only ever shown to the user once, it's not stored/written down beyond the users single use for a login and working from the assumption that everything else is secure (it's not, but I want to get this bit right and then move onto other areas) - is a password of this complexity secure against common forms of attack?

Unless I am mistaken, 17 characters puts the password out of the realms of a rainbow table (16 characters max i read.. I am happy to be corrected).

As I understand it, the number of possible combinations exceeds 29 nonillion, making it beyond the reasonable limits for a brute force in under 24 hours.

The account also has a 5 try lockout applied to it with a 30 minute unlock.

I know there is the possibility of the password being guessed at random first time (anything is possible) - but is there anything blindingly obvious I have missed here?

Fazer87
  • 101
  • 3
  • 1
    [take a look at diceware](https://en.m.wikipedia.org/wiki/Diceware) – Tobi Nary Mar 24 '16 at 16:10
  • 5
    If you are only showing the password to the user once, and the user only uses the password to log in once, then **why do you need a password for the user to enter in the first place?** Just make a one-time access token exchanged directly between the relevant systems. – user Mar 24 '16 at 16:48
  • 1
    I agree with you @MichaelKjörling. :) – Lucian Nitescu Mar 24 '16 at 16:50
  • If `never saved/recorded anywhere`, how do you verify the password when the user uses it? I assume that you are bcrypting it? – Neil Smithline Mar 24 '16 at 17:10
  • Is your question simply "Is a random, 17 character password from a 70-character set secure?" – Neil Smithline Mar 24 '16 at 17:11
  • 1
    How do you verify that the person looking at the screen should be given a new account for 24 hours? – TTT Mar 24 '16 at 17:58
  • The world has managed to promote the idea that passwords need to be random letters and numbers and easy for a computer to guess. Reality suggests that it's harder for a computer to guess something like a 3-4 word phrase that is personal to you that you've not shared with anyone. So instead of a random character password, why not make a password generator that created a small phrase around 4 words long? Maybe implement a rules that says the password is trashed if it's not over 16 characters long if you're still concerned about rainbow tables? – xorist Mar 24 '16 at 18:11
  • Plus, it will be easier to give a user the password, for example, it could generate a password like "Honey Computer Ice Phone." and you could easily tell that to someone and they could easily remember that. Whereas if you just had random letters and numbers (i.e. "Dd$h2@") you'd have to write it down for them to remember, which might pose different risks. – xorist Mar 24 '16 at 18:14
  • This forum post in security should help answer your question abour rainbow tables. http://security.stackexchange.com/questions/60691/length-of-passwords-that-are-rainbow-table-safe – xorist Mar 24 '16 at 18:15
  • 1
    I don't know if the person who gave this task to you approves of your posting the entire concept on Stack Exchange. – Deer Hunter Mar 24 '16 at 18:21
  • @DeerHunter - I agree with you. Though you could argue, if it's truly secure, you should be able to publicly post your algorithm. (Though you probably wouldn't want to.) – TTT Mar 24 '16 at 18:24
  • @MichaelKjörling - in short, because I am a developer tasked with doing exactly what I have been told and a one-time token was rejected... therefore, While not happy abou tit, I am at the end of the day a contractor with bills to pay – Fazer87 Mar 25 '16 at 15:04
  • @TTT - the user has to pass through AD login first and be a member of an AD group which is emptied and repopulated daily – Fazer87 Mar 25 '16 at 15:05
  • @DeerHunter - this isn't the entire concept, just a small fraction of it, obscured and changed to the point where I hoped your answers would be relevant. The actual problem I am working is different, but follows a similar principal and I was hoping that answers to this question could be applied to the issue I am actually facing. – Fazer87 Mar 25 '16 at 15:08
  • @Fazer87 - I'm curious why, if the user is already authenticated through AD, that you need them to re-authenticate with another password? Could you just skip the additional password? – TTT Mar 25 '16 at 15:10
  • @TTT cant go too deep into the actual specifics, but it's a contract client wanting to homebrew 2FA with single use "token passwords" for a small personal project due to a deep distrust of anything not coded by the previous cowboys he's hired. I'm also working within the confines of a pre-existing application/platform that has been cobbled together over years with no real forethought and I am the latest victim to extend it with absolutely no chance of a rewrite budget.. and again, contractor, bills to pay so I want to make the best of the bad. – Fazer87 Mar 25 '16 at 15:19

2 Answers2

3

The smaller problem I see is you've said "random" without defining it. If you are using a cryptographically secure pseudo-random number generator, you're fine. If you're using random(), you're not fine because the output of random() is predictable. random() is useful only for statistical analysis, not security applications.

What's going to be far more important to your system's success is usability. If you're expecting your users to type 17 random characters, they're probably going to blow through your 5-tries rule in the first minute, squinting at a weird font, trying to differentiate O from 0, 1 from l, l from |, ‐ from ‐, and other characters with similar glyphs. Dancing on the shift key while you type also introduces drawbacks. As someone who has to suffer from these awful password generators where cut-and-paste has been cruelly disallowed by the "security experts", I can tell from your description that it already suffers from this fatal flaw, and that your users will despise it. Instead of a 70 character set, consider limiting it. Draw from just the upper case alphabetic characters, or draw from the set of [0-9] and [a-f]. Another option mentioned was diceware, which would enable you to generate multi-word "correct horse battery staple" types of passwords. These are unambiguous and easy to type, although much longer.

You can easily perform the math to determine the "guessability" of either the restricted wordlists or limited character set approaches. And you can tune it so the amount of uncertainty exceeds your requirements. You've said a 1-in-29-nonillion chance is a risk you're willing to accept, but would you settle for a one-in-an-octillion chance, or a one-in-a-septillion chance? Reduce the length to match your risk tolerance, and you'll inconvenience your users even less.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • Regarding your first paragraph, of course that is theoretically true, but is random() *practically* predictable with only 240 total attempts? – TTT Mar 24 '16 at 18:59
  • It depends on the implementation, but it's possible if random() is seeded by something predictable, like a clock. But that's not your only issue here. As an attacker, I may not care which account I hack, as long as I get in. I'll try account A00001 five times, then move on to account A00002 five more times, and so on. Depending on how many accounts you assign, I could make thousands of guesses per day, not just 240. – John Deters Mar 24 '16 at 19:23
  • Hmmm, my gut feeling is that guessing 5 times per account doesn't help you that much. It's obviously better than trying against just 1 account, but I'm not sure how much better (in comparison to all those attempts against a single account). I may wander over to math. – TTT Mar 24 '16 at 19:34
  • Instead of trying to 'math' your way out of it, please just use a tested CSPRNG. See https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator for more info. – John Deters Mar 24 '16 at 20:38
  • The math I was referring to was regarding your 2nd point in the comment - that you can attempt to hack many accounts. I understand the problems with PRNG when talking about offline attacks. I'm not convinced yet that they could be realistically used for an online attack with a lockout after 5 attempts. – TTT Mar 25 '16 at 15:15
  • Hi, Random is seeded, but not by a clock in this scenario. Point taken on useability. This answer actually translates fairly nicely back to the real non-pseudo'd problem I am facing and will take this back to the powers that be. ~Thanks – Fazer87 Mar 25 '16 at 15:16
  • @TTT, look at the attack on EMV from ATMs using poor random number generators a few years ago. http://www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf Ross Anderson's group at Cambridge was able to guess at the non-random sequence, and make successful attacks against a three-tries lockout system. What the attacker does is fail a bunch of times, but as they fail they observe the random numbers used. Once they know the sequence, they figure out the initial state of the generator for the next time, which does succeed. – John Deters Mar 25 '16 at 15:48
  • @JohnDeters, interesting article, however that isn't even close to a fair comparison. They had a lot of information. In this case, we're talking about 10 attempts per hour with the only feedback being yes/no. I'm not saying it's impossible to crack the PRNG using this method, but it seems highly unlikely. Maybe if you knew the exact time that the password was created you'd have a fighting chance, but I don't see how you would even know that. – TTT Mar 25 '16 at 18:24
  • That being said, I think you've convinced me regarding random() anyhow, because the point is moot. It doesn't matter if random() can practically be predicted in this case, because, I agree- use a CSPRNG and be done with it! – TTT Mar 25 '16 at 18:30
  • @TTT, consider the attacker may know the algorithm. It's also possible that if the password generator is seeded by the clock, and the password creation task is started by cron every night at midnight; the passwords could become amazingly predictable. Bad implementations aren't always recognizable as such until someone goes looking for them. – John Deters Mar 25 '16 at 19:54
  • @JohnDeters Agreed! – TTT Mar 25 '16 at 20:28
1

From what I gather, you're killing a fly with a sledgehammer.

Since you lock out the account after 5 attempts, and unlock it after 30 minutes, and delete the account after 24 hours, then in the worst case scenario, an attacker can attempt 10 tries per hour, or 240 total passwords before the account is gone. So your password only needs to be difficult enough so that it is unlikely to be guessed in 240 tries. With a space of 70 characters, a password of length 4 should be plenty secure (24 million possibilities). If you're paranoid, make it 5 characters and be done with it.

But you may be wondering:

"What if an attacker compromises my server? If the passwords are short they may be able to brute force my password hashes and get access to everyone's password!"

But my response to that would be:

"And do what with them?"

TTT
  • 9,122
  • 4
  • 19
  • 31
  • 1
    What if the attacker managed to somehow get the encrypted version of the password? – xorist Mar 24 '16 at 18:29
  • @l1thal - How did an attacker get it? – TTT Mar 24 '16 at 18:35
  • I would imagine some vulnerability that enabled him to leak the passes that were stored for that day to himself somehow. – xorist Mar 24 '16 at 18:36
  • Oh- I see what you mean. I'll rephrase your question: suppose the passwords are stored on the server either encrypted or hashed, and somehow the encrypted or hashed version (with it's salt) is leaked out to an attacker. If that happened, then wouldn't you want a longer password so it would be harder for them to determine the password (within 1 day)? Does that restate your question fairly? – TTT Mar 24 '16 at 18:40
  • Yes, that works. But I was pointing that out because your answer seems to only suggest the attacker's only vector for penetration is the actual legitimate login location. I think it would be good to keep in mind that nothing should be considered 'unhackable' and consider the possibility of such things (hashed/encrypted passwords) being extracted from any application – xorist Mar 24 '16 at 18:42
  • The answer is, we always have to assume some amount of other general security precautions are in place, which would make the case you described not possible. Under normal circumstances, when we talk about an attacker gaining access to where the passwords are stored, it's an all or nothing scenario. They either can't access it, or if they do, that means they have penetrated the server and have full access to the entire password database. But once they are on the server, they already have access to all the data they could get by logging in with someone's account. – TTT Mar 24 '16 at 18:45
  • And that's exactly what the 2nd half of my answer is addressing. My point is that if someone hacks the server, they already have access to everything anyway, so who cares if they also have the passwords at that point. The passwords are to protect outside access. They are useless against someone already on the server. – TTT Mar 24 '16 at 18:46
  • Ah alright. I re-read the question and I'm realizing that my point is voided. Sorry about that, I must've misread. – xorist Mar 24 '16 at 18:48
  • No worries! It was a good discussion. :) – TTT Mar 24 '16 at 18:49
  • Indeed it was! I'm glad I didn't post an answer; I would've looked crazy. lol. – xorist Mar 24 '16 at 18:52
  • This seems very insecure. Such short passwords are likely to be cracked within 24 hours if the password table is leaked via something like a SQL injection attack. – Neil Smithline Mar 25 '16 at 15:09
  • Fantastic answer with good discussion. Of course I don't expect a true answer given the amount of scenario changes implemented when making thsi psuedo-relevant question - but it has given me a good set of further questions to ask. It goes wihtout saying that any password storage would be encrypted, servers are up to date patched, firewalled etc but I wanted to know if I was missing anything anf this is exactly what I needed to see. Thanks – Fazer87 Mar 25 '16 at 15:13
  • @NeilSmithline - I agree with your statement, and disagree that it is relevant. You're talking about coding mistakes. A memory leak on the server could expose all plain text passwords that other users are entering in too. Or a really big screw up would be the login page could display the password of the last logged in user. Or (a little more realistic), a non-logged in user can gain access to a page they shouldn't see unless logged in. – TTT Mar 25 '16 at 15:19
  • @NeilSmithline - btw, how is your example different than the one l1thal gave? I think the previous discussion should go the same way. Though I'm guessing you want to defend that position a bit more. :D – TTT Mar 25 '16 at 15:25