Jump to content

Password Generator - faster and simpler than current solutions


Recommended Posts

Description:

 

I tried some of the current workflows that act as password generators but none of them were simple enough for my purpose so I came up with this one.

 

From my perspective (and based on my needs) a password generation tool should be something straightforward - it doesn't need to require an active internet connection and doesn't need to offer complex options as the result. Having said that, this workflow doesn't aim to generate passwords that are the topmost in terms of security level - it tries to balance simplicity and performance with a good amount of security.

 

Some output examples (using its default length):

  • DeCW2V4SKBXWZVv
  • 4s02A6M-uOsDA6o
  • cGtrW8Hz-TssPaK

As part of the password recipe I use symbols, lower/upper case letters and numbers. All of them are randomly mixed up. The default length is 15 (so you can just call `password` to generate a new password) but you can overwrite this config by passing in another number, e.g. `password 15`.

 

The generated password will appear as part of a system notification and will be copied to the clipboard. 

 

Where:

 

Either go to the Github project page or download the workflow from Packal

 

 

Demonstration:

 

password-generator.gif

Edited by npufal
Link to comment

Why and what:

 

I tried the current workflows that act as password generators but none of them were simple enough for my purpose so I came up with this one.

I'm not sure how this is simpler to use than my password generator, but whatever.

Unfortunately, your workflow uses Ruby's rand() function, which is not a good source of entropy, and therefore not very secure.

You really should use SecureRandom instead, which uses /dev/urandom as a source of entropy (the best you'll get without having the user bang on the keyboard like a monkey).

 

Password generation should be something really simple from a script perspective - it doesn't need to require an active internet connection in order to reach a specific service that generates it for us.

 

Indeed, a password generator should absolutely not rely on online services, or any other services not under the user's control. Asking a webpage to generate your passwords for you is a very bad idea (unless you know and trust the operator 100%).

Link to comment

You are totally right about the entropy, but my intent here was to keep it as simple as possible - it's not intended to be a security tool.

 

I use 1Password to store all my passwords and if I'm looking for a really strong password I will just tailor a password recipe that fits my needs and will end up creating it there - that's what I meant by "as simple as possible".

 

I personally don't see workflows as a way to accomplish complex tasks and/or the need for them to do it with the maximum excellence. The password generated by it might not be the strongest but neither it's the weakest - it's an average password that the user can quickly grab without thinking much. 

 

Your tool is very good by the way - it would be my choice if I were looking for something more robust.

Link to comment

It's like two or three extra lines of code to use SecureRandom instead and improve the security of the generated passwords.
 
I appreciate and understand your attitude to workflows, but it's not a universal one. As a result, I think it's important that you mention that you don't consider your workflow appropriate for generating super-secure passwords.
 
I also keep all my passwords in 1Password, but I wrote my own generator because I dislike the lack of transparency in 1Password's. There's no indication of how it calculates password strength, and the algorithm (exactly X digits and Y symbols) is a bit suspicious to me. 
 
Also, it doesn't support a super-useful technique for generating hard-to-crack passwords: non-ASCII characters. Throw a ü or ø into a password, and it is way more secure (most crackers only use ASCII).

Link to comment

I appreciate and understand your attitude to workflows, but it's not a universal one. As a result, I think it's important that you mention that you don't consider your workflow appropriate for generating super-secure passwords.

 

Very much agreed. I can’t think of a single person I’ve ever talked to that would knowingly pick a less secure password generation mechanism. Why would you ever? Particularly if you mention right in the title “faster and simpler than current solutions”, not saying “because it is less secure” seems like a blatant omission.

Not saying you did it on purpose or anything, but I’m starting to notice a worrying trend1 (I do hope it’s not an actual trend).

It’s fine to say “I did this because I wanted to build one myself”, “others don’t work exactly as I want”, “I think the tradeoffs made by others are incorrect”. Heck, if someone specifically complains that a certain workflow doesn’t have a feature and yours does, it’s even fine to say “try mine, as I’ve implemented what you want”. But to outright say yours is better (by whichever metric) when the quality of results isn’t up to par and not even explain right in the top post which tradeoffs you made, that I do not think is OK.

As for using online services, mine is one of the ones who does, and since I do agree with the criticisms, it does take precautions. Not only does it use multiple services at the same time, one of them is a source of true randomness (as opposed to any other system we have on our machines that are merely pseudorandom), it takes way more data than it actually needs from all services, and it still jumbles everything together in the machine, ending up with three sources that come together to generate the password, negating the possibility that even if the website owners were malicious, they could figure it out just by the data they send you.

Again, I’m not lashing out or anything, but I am painfully aware my tone can sometimes seem confrontational in writing, so I want to assure you it is not, and I’m writing with the best of intentions. You seem like a reasonable person with the best of intentions, and I have no reason to believe you have anything other than goodwill with sharing the workflow. I did, however, want to point out what I found disconcerting about the initial post, and why there are so many password-generation workflows. Each one of us wants to make different tradeoffs and do what we believe is best. Openly discussing those solutions amongst us is a big win for security.

----------

1 And not only is that workflow not faster, it doesn’t do nearly the same and doesn’t work as well.

Link to comment

As for using online services, mine is one of the ones who does, and since I do agree with the criticisms, it does take precautions. Not only does it use multiple services at the same time, one of them is a source of true randomness (as opposed to any other system we have on our machines that are merely pseudorandom), it takes way more data than it actually needs from all services, and it still jumbles everything together in the machine, ending up with three sources that come together to generate the password, negating the possibility that even if the website owners were malicious, they could figure it out just by the data they send you.

 

To clarify my earlier statement, using passwords generated by an online service is a very bad idea; using them as a source of entropy, like your workflow does, is an entirely different matter. Combining multiple sources of entropy is a Very Good Thing™, and a compromised source can't defeat your security if used in the right way.

Link to comment

People have different needs. Not everyone needs/wants to have the most secure password in the world. I totally agree that, when talking about security, we need to be careful and should be mindful - in that regard I really doubt that since my first implementation here the workflow was generating a password that is below a minimum of what can be considered a good one.

 

I totally appreciated deanishe feedback by the way - my focus was to go really simple so I started with rand() but as he reminded me SecureRandom is built into Ruby and offers a much better entropy level.

 

Also, I never said my tool was the best, so I didn't get the comparison with the other post. I just said I wanted something simpler that fitted my needs. Programming is about trade offs, so there will never be such a thing as a silver bullet tool - it's up to the user to decide and it's up to us to clarify in which points our tool excels and in which it don't. 

 

Based on all the feedbacks I also updated my first post making it clear to the users that this workflow is not intended to offer optimal security  ;)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...