StrongPassword — Get a strong password from true random values

[vitor]

Run sp to generate a password from true random values provided by RANDOM.ORG which are further shuffled.

Download | Source

[vitor]

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 April 11, 2014 by Vítor

[deanishe]

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?

[vitor]

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.

[deanishe]

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 April 12, 2014 by deanishe

[vitor]

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.

[deanishe]

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.

[vitor]

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.

[deanishe]

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.

[vitor]

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.

[deanishe]

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

[2pilvic]

Please, does a workflow exist to encrypt files (multiple) directly into Preview.app?

[lmachado]

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 July 8, 2014 by lmachado

[vitor]

You must be using an older version of OS X, lmachado. This problem was encountered before. I’ve made a fix available.

[lmachado]

awesome! works great! thanks again! 

[vitor]

Update.
 
It now uses sp instead of strongpassword and has an option to get passwords without special characters. I thought before of eventually adding this, but did it now following a contribution from stuartcryan.

[stuartcryan]

Thanks Vítor you are a gentleman and a scholar

Stuart

[Martin]

This works nicely, thanks.

 

Does it handle (avoid) ambiguous characters (like capital i and lowercase L)?

[vitor]

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

[Martin]

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

[vitor]

Update.

It now uses OneUpdater, so this should be the last time you need to manually update.

[vitor]

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.
 

[vitor]

Update.

• Rewritten in JXA.
• Added default_length Workflow Environment Variable for custom default password size.
• Removed option for password with special characters.
• Now uses ANU QRNG and shuffles on top of that.
  

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

[Samplex]

Please dont use slow sites like ANU QRNG, this site has to much latency 300+ms and take to long to generate a password.

And why remove password that contain special characters?

 

Edited May 13, 2022 by Samplex

[vitor]

5 hours ago, Samplex said:

slow sites like ANU QRNG

 

It’s faster than the previous version of the script when including special characters, so that doesn’t really seem like a concern. It’s not like it’s too slow for a user-generated action. But if you have better suggestions, I’m open to them. The requirements are that it uses true randomness and that the result is returned as a string or JSON. For the previously used solutions I had to parse the HTML response, which worked fine but has the potential to break on its own due to website changes (though granted, those sources are unlikely to). One of the goals of the update was more robust future-proofing, hence removing the Ruby dependency (before its inevitable removal from macOS) and changing the source to something with a cleaner output.

 

5 hours ago, Samplex said:

And why remove password that contain special characters?

 

Given the new source, I’m still deciding on the approach for that. I may append every ASCII punctuation symbol to the returned string a random number of times for each, then make them part of the final shuffle.