Jump to content

Recommended Posts

Generate secure random passwords from Alfred. Uses /dev/urandom as source of entropy.
 
demo.gif 
 

Features

  • Passwords can be generated based on strength or length.
  • Offers multiple generators, including based on real words and pronounceable pseudo-words generated with Markov chains.
  • Shows the strength of each generated password.
  • Strictly offline — it's safer not to outsource your security to a webservice.

Download & Installation

Get the workflow from the GitHub releases page or Packal.

Basic Usage

  • pwgen [<strength>] — Generate passwords of the specified strength. Strength can be either a number (1 or above) or a specific amount of entropy in bits, e.g. 128b. The default is 3, which corresponds to 96 bits of entropy.
  • pwlen [<length>] — Generate passwords of the specified length. Default is 20. Strength differs depending on the generator (e.g. for 20 characters, strength can vary between 50 and >100 bits of entropy).
  • pwconf [<query>] — Alter the default strength/length and activate/deactivate different generators.

Password Generators

Several different password generators are included by default, including:

  • ASCII letters, digits and punctuation
  • ASCII letters and digits
  • ASCII letters and digits, excluding easily-confused letters and numbers
  • Digits only
  • Pronounceable, randomly-generated gibberish words
  • Dictionary words

Password Strength

Please see the GitHub README for detailed information on the strength of the generated passwords and which settings you should (or shouldn't) use.

 

The default strength of 3 is sufficient for most purposes (~6.5 years to guess the password on 2015 dedicated password-cracking hardware). Use 4 for very important stuff.

Edited by deanishe

Share this post


Link to post
7 hours ago, mrchow19910319 said:

 

Why does it show password that has 11 characters when I typed in pwlen 10?? 

 

 

Because it's not reasonably possible to keep re-running the workflow until it produces a random password of precisely the right length.

 

Edited by deanishe

Share this post


Link to post

Updated today. Hopefully, the occasional hanging should be fixed.

 

It also now conceals copied passwords from clipboard history managers by default.

Share this post


Link to post

Thank you for the quick fix, this appears to have fixed the occasional hanging (a restart of Alfred was required, I'm using Alfred 3.3.1 on macOS 10.12.4)!

Share this post


Link to post

I noticed that there is an update to the workflow. However, when trying to update with the built-in workflow update option it seems to get stuck (the attached image is just showed indefinitely) and the update is not downloaded/installed. I'm using Alfred 3.3.2 on macOS 10.12.5. Pasting the last part of the debug report:

 

12:25:36 update.py:281 DEBUG    Release `v1.0` : https://github.com/deanishe/alfred-pwgen/releases/download/v1.0/Password_Generator-1.0.alfredworkflow
12:25:36 update.py:352 INFO     11 releases for deanishe/alfred-pwgen
12:25:36 update.py:363 DEBUG    Latest : Version('2.1.1') Installed : Version('2.1.0')
12:25:36 workflow.py:1894 DEBUG    Cached data saved at : /Users/candstef/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/net.deanishe.alfred-pwgen/__workflow_update_status.cpickle
12:25:36 workflow.py:2541 DEBUG    Downloading update ...
12:25:36 background.py:178 DEBUG    Command arguments cached to `/Users/candstef/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/net.deanishe.alfred-pwgen/__workflow_update_install.argcache`
12:25:36 background.py:182 DEBUG    Calling [u'/usr/bin/python', '/Users/candstef/Library/Application Support/Alfred 3/Alfred.alfredpreferences/workflows/user.workflow.B49B1006-ED08-4990-84A3-E00E44968CBF/workflow/background.pyc', u'__workflow_update_install'] ...
12:25:36 workflow.py:2221 DEBUG    Workflow version : 2.1.0
12:25:36 background.py:187 DEBUG    Executing task `__workflow_update_install` in background...
12:25:36 workflow.py:1384 DEBUG    Downloading and installing update ...
12:25:36 workflow.py:2263 DEBUG    Workflow finished in 0.625 seconds.

20170614_12-06-32_screenshot_update_Password_workflow.png

Edited by cands

Share this post


Link to post

Thanks that fixed it! I have actually used Fixum before so I thought that this was complete (and I have not been bothered by high CPU usage from Python workflows lately), nevertheless Fixum now updated 52 workflows and the issue seems to be solved.

Share this post


Link to post

I changed the behaviour of Fixum from only updating workflows affected by the Sierra bug to updating all workflows with a version of Alfred-Workflow older than its own. As I also released a new version of the library, it will probably have updated all your AW-based workflows.

 

 

Share this post


Link to post

That explains it, thanks for the clarification. I came to think of one security-related question - the workflow currently copies the password to the Alfred Clipboard where it can be available for quite some time depending on the settings - would it be possible to copy it in a more secure (transient) way similar to 1Password? I usually remember to delete it manually once I've used it, but I tend to not always remember.

Share this post


Link to post

That's an Alfred bug, tbh. 

 

The workflow marks the copied password as concealed data, so Alfred should NOT record them.

 

I've tested it with other clipboard history managers, and they respect the concealed marker. 

Edited by deanishe
teh grammer

Share this post


Link to post

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
×