I have (re)written my password generator in Rust with support for many different patterns. From completely random ASCII, to memorable diceware-like passphrases, and anything in between, plus extras such as private IP addresses or MACs.
I’ve also classified these patterns for easy accessing, and based on the pattern entropy I provide guesstimates about the effort for a brute force attack.
When it comes to static sites, there are a myriad of solutions for authoring and compiling, but talk about hosting these static sites, and we are still in the early 2000s. I discuss the challenges one faces when hosting, and even make a proposal to solve some of these.
Not every hash algorithm is appropriate in all scenarios, and in fact, very few algorithms are usable in more than a couple of situations. Even worse, using the wrong algorithm will lead in the best case scenario to performance problems, but in the worst case scenario to security issues and even financial loss. Thus, knowing which algorithm to pick for which application is crucial.
Therefore I’ll try to summarize how I approach the topic of hashing, including use-cases, recommended algorithms, and links to other articles.
Jean Yang:
Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.
As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.
Good stuff to be reminded of. That reminds me: You are not Google/Amazon/LinkedIn.
An argument in support of software packages that come in the form of a single binary executable (statically linked or portable), that one can just copy anywhere in ${PATH} and execute, without needing sudo, or downloading half the distribution’s packages as dependencies.
While I was trying to identify why my-Go-based project took more than three times to execute than a similar Bash script (for a code-path that amounted to just a few stderr writes), I found that many of the Go packages (including some in the built-in library) have quite “heavy” static initializers, which due to how Go initialization works are always executed regardless if I use them for a particular code-path or not.
Also, with the newly introduced GODEBUG=inittrace=1 in Go 1.16 developers can now investigate the cost of static initializers of their dependencies, thus I wanted to raise the awareness of this issue.
