Jump to content
vitor

StrongPassword — Get a strong password by leveraging multiple sources

Recommended Posts

Get strong passwords by combining up to three sources — https://www.grc.com/passwords.htm (unless you choose to have a password without special characters), http://www.random.org/passwords/, and ruby itself. There’s at the end a technical explanation on how it works.

 

Call sp and the workflow will get a (default and maximum of) 64 characters random password, and copy it to your clipboard.

 

FYSmmRX.png
tzN4O8E.png

 

You can also specify a number after the keyword, and it’ll truncate the password to that.

 

SqOlIOn.png

 

Technical Details
I strived to keep the code very readable; inspect it at will. What this does is get a (about, due to some HTML escaping) 63 characters password from https://www.grc.com/passwords.htm and another (8 passwords, each consisting of 24 characters, joined together) from http://www.random.org/passwords/. If you opt for a password without special characters, only the latter will be used. It then picks a pseudorandom number (one of the instances where ruby is used, for speed) between one and two thirds of your chosen password length (truncated at, and by default, 64), saving that number (lets call it “x”) and the remainder (lets call it “y”) separately. From the first password, x number of characters will be chosen from random positions on the string (it’s actually an array, but that may start to become a bit too technical), and from the second one, y characters will be picked. The results are then joined together, and shuffled a last time between them, to produce the final result.

 
Download | Source

Edited by vitor

Share this post


Link to post

Update.

 

Thank you brandonjp for contributing the code to truncate the password to the specified number of characters.

In addition, the notification will now indicate how many characters the password consists of.

Edited by Vítor

Share this post


Link to post

Good idea, but grc.com/Steve Gibson is not a confidence-inspiring source of passwords.

Any chance of getting the passwords from a more reputable source?

Share this post


Link to post

Fair point. I’ve updated the way it works (technical details in the top post). It still uses grc.com as one of the sources, but it’s just one of the parts in a bigger system, and not exclusive (it’s included mainly for its use of non alpha-numeric characters, that random.org does not use). Not relying on a single source is probably a good idea. Tell me what you think.

Share this post


Link to post

Good work.

I'm getting a GateKeeper error because your bundled "notificator" app isn't signed. Is there a reason to use it instead of puts and a standard Alfred notification?

Edited by deanishe

Share this post


Link to post

Thank you.
 
Yes, there’s a reason to not use the default notifications, albeit a purely aesthetical one. Alfred’s notifications still show Alfred’s icon, and I like my workflows to have a more “contained” look. I’ve developed notificator some time ago as a public domain alternative to terminal-notifier, the why is explained in the repo, so I won’t go into detail here.
 
However, that warning truly is a bother, and not an optimal experience, so I’ve since come to include terminal-notifier into some of my other workflows, but I had not updated this one since it was one of my first (maybe the first), and it was so simple I didn’t think it was worth it, as I wasn’t even sure anyone else used it (turns out some people do).
 
I’ve now updated it to use terminal-notifier as well, so you should not get that error anymore. I’ve also made some minor optimisations by removing some temporary holders.

Share this post


Link to post

Is terminal-notifier signed, then?

Perhaps it's just me, but I'm not a fan of including terminal-notifier or the like simply to show the right icon. It's not a big deal if it's only one or two workflows, but I'd hate for everybody to have the same idea, so I end up with 50 copies of it in my workflows folder.

Share this post


Link to post

Yes, terminal-notifier’s releases are signed.
 
Terminal-notifier is relatively small (a 90KB addition), so even with a hundred workflows, it would amount to less than 10MB. I do understand your concern, but to me, it’s an acceptable tradeoff. By this I don’t necessarily mean “in my opinion this should be universally acceptable” but “personally, this is how I prefer it to work”. As a designer, experience is incredibly important to me, and that small variation does make a difference to me. I started programming exactly because I’d like certain tasks to work a very specific way, and so I can make them myself (I continue in part because I also find it fun to think through and solve those problems). When it’s operational, I do go through the extra work of making it function optimally to other users, but I strive to not make it worse for myself, if it’s a tool I built for personal use. If you read the conversation in PinAdd’s thread, you’ll see that it evolved quite a bit from feature requests, but one of my concerns when adding something was always to not make it worse for those who liked the way it already worked, experience-wise.
 
When you say you’d hate for everyone to do the same with terminal-notifier, I don’t think me not doing it would stop that, as the idea is already out there (and I have two other workflows that have been employing it for some time). Making it work this way does require some minor amount of extra work, both the benefits and drawbacks of it being highly debatable, so it is a choice similar to others when developing. The use of notificator did have a disadvantage (the warning you saw) I believe to be greater than the benefit it brought, and even then it was a simple fix of giving it once the permission to run, but again, experience matters. The way it works now is the tradeoff I want to make.

I do know you personally have the capability to change this to work how you mention, and it’s because of that knowledge (at least in part) that you understand this difference enough to care (and that is definitely a good thing).

In sum, I currently have no intention of making such modification in an official capacity, as it is a deliberate and considered choice. This code is, however, released to the public domain, so my decision is in no way locking out alternatives. I’ve uploaded (link available for a few days) a version that uses Alfred’s notifications system; I had to slightly alter the output message as otherwise it wouldn’t be able to show the full message, as it would get truncated.

sZcTXp3.png

Share this post


Link to post

Don't get me wrong, I fully appreciate why you did it. It's not the size of it that bothers me, more the idea that there are 50 copies of the same thing.

It's silly, I know, but it irks the coder in me in much the same way I imagine the wrong icons in the notifications bother you.

As you wrote your own notifier, do you perhaps know if GateKeeper will complain if a Ruby/Python script tries to post a notification via their respective Cocoa bridges?

I'm thinking of trying to add notifications to my Python workflow library, but there's no point if GateKeeper's going to kill it.

Share this post


Link to post

I certainly understand that, and agree, even. In that regard, it’s no different of including a library, though. Maybe that’s an opportunity for improvement in Alfred, a centralised and controlled system that can tap into and include packaged libraries/applications that would be locally accessible. Something that would allow you to define shared dependencies — if a workflow that needs one of these asks for it and it’s not included, download it, else, use the one already present. Not necessarily a simple task (not only the code but the system itself would have to be worked on), but it should be feasible.
 
I do not know if gatekeeper will complain in that case, but I can make a fairly good guess, based on my experience building notificator. Mavericks does give you access to the notifications API via applescript (that’s what notificator uses); however, the icon it shows is connected to the bundle ID of the app, so if you just call it via applescript, the icon it’ll show is from AppleScript Editor. Even if you change the app’s icon, if you already put out a notification with it before and the bundle ID is unchanged, it’ll still show the previous icon. Notificator is only an app (as opposed to a script) due to this limitation, and even in terminal-notifier I employ a script to automatically download it, set a new icon and bundle ID.

Considering all this, as long as you don’t care about having a custom icon and don’t need to build an app (in the sense of having a .app extension), it will likely be fine for you to include that.

Share this post


Link to post

I certainly understand that, and agree, even. In that regard, it’s no different of including a library, though. Maybe that’s an opportunity for improvement in Alfred, a centralised and controlled system that can tap into and include packaged libraries/applications that would be locally accessible. Something that would allow you to define shared dependencies — if a workflow that needs one of these asks for it and it’s not included, download it, else, use the one already present. Not necessarily a simple task (not only the code but the system itself would have to be worked on), but it should be feasible.

I hope he doesn't mind my mentioning it, but Shawn is currently working on something to do exactly this. It'll work for common utilities like terminal-notifier and cocoaDialog (which are both built in, IIRC) and for versioned PHP and bash libraries.

Unfortunately, it looks like Ruby and Python won't be supported for a long time, if ever, due to the way bundler and pip work :(

 

I do not know if gatekeeper will complain in that case, but I can make a fairly good guess, based on my experience building notificator. Mavericks does give you access to the notifications API via applescript (that’s what notificator uses); however, the icon it shows is connected to the bundle ID of the app, so if you just call it via applescript, the icon it’ll show is from AppleScript Editor. Even if you change the app’s icon, if you already put out a notification with it before and the bundle ID is unchanged, it’ll still show the previous icon. Notificator is only an app (as opposed to a script) due to this limitation, and even in terminal-notifier I employ a script to automatically download it, set a new icon and bundle ID.

Considering all this, as long as you don’t care about having a custom icon and don’t need to build an app (in the sense of having a .app extension), it will likely be fine for you to include that.

Thanks for the info. I would be calling Cocoa classes directly from Python, not via AppleScript. I'll give it a go and see what happens. I imagine I'll get the silly Python rocket icon, though, even if GateKeeper doesn't complain :(

Share this post


Link to post

thanks for the workflow! downloaded it today from both packal and github and i'm getting the following error whether I pass an argument or not:

 

[ERROR: alfred.workflow.action.script] Code 0: getPassword.rb:11:in `rand': can't convert Range into Integer (TypeError)

from getPassword.rb:11

 

nothing makes it to the clipboard. any ideas? thanks!

Edited by lmachado

Share this post


Link to post

Not at all. Those characters are only ambiguous in certain typefaces, so ambiguity is subjective. These are intended to be as random as possible.

Share this post


Link to post

Not at all. Those characters are only ambiguous in certain typefaces, so ambiguity is subjective. These are intended to be as random as possible.

 

OK, I understand your point - they are ambiguous in the OS X system default font though, but that's why God invented copy 'n paste I guess :)

Share this post


Link to post

Update.


New icon, as well as some updates to the messages.


To update, download the latest version (same URL) or wait a few days (15 or less) and it’ll prompt you to on next usage, since it uses OneUpdater.
 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...