If you're a web developer, you've probably had to make a user account system. The most important aspect of a user account system is how user passwords are protected. User account databases are hacked frequently, so you absolutely must do something to protect your users' passwords if your website is ever breached. The best way to protect passwords is to employ salted password hashing. This page will explain why it's done the way it is.

There are a lot of conflicting ideas and misconceptions on how to do password hashing properly, probably due to the abundance of misinformation on the web. Password hashing is one of those things that's so simple, but yet so many people get wrong. With this page, I hope to explain not only the correct way to do it, but why it should be done that way. //

To make it impossible for an attacker to create a lookup table for every possible salt, the salt must be long. A good rule of thumb is to use a salt that is the same size as the output of the hash function. For example, the output of SHA256 is 256 bits (32 bytes), so the salt should be at least 32 random bytes.

A security researcher is recommending against LastPass password manager after detailing seven trackers found in the Android app, The Register reports. Although there is no suggestion that the trackers, which were analyzed by researcher Mike Kuketz, are transferring a user’s actual passwords or usernames, Kuketz says their presence is bad practice for a security-critical app handling such sensitive information.

“Use longer, stronger passwords.”

For storing rarely used secrets that should not be kept on a networked computer, it is convenient to print them on paper. However, ordinary barcodes can store not much more than 2000 octets of data, and in practice even such small amounts cannot be reliably read by widely used software (e.g. ZXing).

In this note I show a script for splitting small amounts of data across multiple barcodes and generating a printable document. Specifically, this script is limited to less than 7650 alphanumeric characters, such as from the Base-64 alphabet. It can be used for archiving Tarsnap keys, GPG keys, SSH keys, etc.

The script is implemented in Python, since this is one of the most widespread interpreters, is compatible with both Python 2 and Python 3, and has one external dependency, the iec16022 binary. On Debian-based systems these can be installed using
apt-get install python3 iec16022

The script accepts any ASCII sequence and generates an HTML page sized adequately for printing on A5 paper that contains multiple ISO/IEC 16022 (Data Matrix) barcodes. The barcodes can be read with any off-the-shelf software, e.g. ZXing. Even if up to 30% of the barcode area is corrupted, the data can still be recovered. //

This page can now be printed on a laser printer (with no margins) and laminated. If done properly, it is likely to outlast the service for which it holds the secrets.

DiceKeys is a physical mechanism for creating and storing a 192-bit key. The idea is that you roll a special set of twenty-five dice, put them into a plastic jig, and then use an app to convert those dice into a key. You can then use that key for a variety of purposes, and regenerate it from the dice if you need to. //

Note: I am an adviser on the project. //

Q • August 24, 2020 6:57 AM

I would very very uncomfortable about having not only the physical key available to any thief or agent that decides they want it, but also having it available in a vulnerable leaky phone and app that all measure of companies and people can spy upon. Just no.

Stuff like this should only be in my head IMO. Then I get to decide if it ever gets revealed to someone else.

Ari Trachtenberg • August 24, 2020 7:20 AM

"mathematically unguessable key" - really Bruce? You know better than to taunt the hackers with hyperbolic language. If anything, the key is "practically unguessable" - but mathematically, it is certainly guessable.

z • August 24, 2020 7:46 AM

Good, cheap and simple random number generator. But it's not that special it's just very practical and it gets rid of most trust issues. But Dice quality can effect entropy, so don't let any academic measure your dice :-D

Sam • August 24, 2020 9:54 AM

What problem is this solving exactly? There are many problems across the entire crpyto ecosystem, but "keys not being random enough" is pretty damn low on the list, and certainly not outweighed by sending your key through a computer-vision based web app.

A Diceware passphrase generator, implemented in JavaScript, that uses the Cryptographically Secure Pseudo Random Number Generator (CSPRNG) in your browser as its source of entropy instead of rolling physical dice.

Hosted Version
https://www.rempe.us/diceware/

Important Features
All random number generation is done in your browser using window.crypto.getRandomValues()
Single page JavaScript application with no communication back to a server
Can be run locally from a Git clone, with all dependencies baked in

Diceware wordlist

Diceware is used to generate cryptographically strong passphrases. Don't let that frighten you away though, a passphrase is just a password made of words you can remember. It is based on the principle that truly random selection of words from a wordlist, can result in easily memorable passwords that are also extremely resistant to attack. Traditional Diceware uses rolls of physical dice, this application uses a strong random number generator in place of the dice. Passwords that are six words or longer are thought to be safe for any very high security applications.

Let us begin with the sincere hope that you do
not have an early demise.

On the other hand, what if you did have a fatal
car accident today? Would your business partner
or mate know how to access critical accounts,
including your on-line banking and brokerage
accounts? Or, would your family know what to
do with your email, facebook, or other web
access points?

The smart solution is to ensure that your key
accounts and passwords are located in the same
place your Will and Power of Attorney docu-
ments are stored. In fact, a complete listing of
all your accounts and policies will aid your fam-
ily in the event you are incapacitated or die.

For sensitive materials, including your financial
accounts, nominate someone you truly trust,
include them in your Will or Power of Attorney,
and make sure they know where to find the
information if needed. Also, check with the
institution to ensure the paperwork is in order to
allow them access without major legal gymnast-
ics (often, this means a “joint account with right
of survivorship”).

For most people, the best solution is to leave a
sealed envelope with a trusted person (family
attorney or your best friend?), to be opened only
in case of death. (You will need to update such a
letter every so often as you change passwords
and/or accounts.)

Even if you have saved your data files to a hard
drive, you still have to be cautious – any IT pro
will tell you the only question about hard drive
failure is when it will happen, not if!

BACKUP OPTIONS
That is the key reason why it is important to
backup the backup.

Possibly you have heard of the 3-2-1 Backup
Rule: have three copies of anything important,
in two different formats (hard drive, solid state
drive, CD, DVD, etc), with one of the copies at
another location, away from your site.

This is good advice, and exactly where you keep
the backup is important.

Why? Just think for a moment about the fires in
California, or the flooding caused by Hurricane
Sandy in the Northeast, or that in the Carolina’s
last year.

If critical backups were merely located in a
different office in the same building, or at a
neighboring site, there would be a great chance
that any such backups would be destroyed, too.
And not only the business data – family records
and pictures easily could be destroyed.

DO NOT LEAVE
WITH YOUR PASSWORDS
By Gil Gillivan

Great piece on not dying with your passwords.

So very true. And a nice reminder of the 3-2-1 backup.

https://www.thebdr.net/articles/IT/adm/IT-DontDie.pdf

Two-factor authentication is an essential security measure that uses your phone to help prevent unauthorized access to your account. It makes it harder to access your account if you lose your phone, but that’s also sort of the point. Thankfully, you aren’t without options if you can’t find the one device you use to verify that you are actually you.Two-factor authentication, by its very nature, is designed to prevent access to your accounts if you don’t have access to your phone (or other authenticating device). Therefore, there aren’t many ways to circumvent this requirement after the fact. There are many ways to prevent this problem from happening, however. So don’t wait until you lose your phone to set them up.

By default, Chrome will now let users know if their credentials are public.

BSD co-inventor Dennis Ritchie, for instance, used "dmac" (his middle name was MacAlistair); Stephen R. Bourne, creator of the Bourne shell command line interpreter, chose "bourne"; Eric Schmidt, an early developer of Unix software and now the executive chairman of Google parent company Alphabet, relied on "wendy!!!" (the name of his wife); and Stuart Feldman, author of Unix automation tool make and the first Fortran compiler, used "axolotl" (the name of a Mexican salamander).

Weakest of all was the password for Unix contributor Brian W. Kernighan: "/.,/.," representing a three-character string repeated twice using adjacent keys on a QWERTY keyboard. (None of the passwords included the quotation marks.)

I don't remember any of my early passwords, but they probably weren't much better. //

Magnus • October 15, 2019 5:31 PM

"I would love to learn what Donald E. Knuth's passwords used to look like."

Knuth just closes his eyes and concentrates and the computer logs him in.

The computer needs a password to log in to Knuth.

Generate a password the bad people can't guess, but you can easily remember.

But after all this talk of GPUs and algorithms and hash speeds there’s one really, really simple solution that will take you 60 seconds to implement and will make your passwords near uncrackable. It’s this:

<add name="AspNetSqlMembershipProvider" minRequiredPasswordLength="30" 

minRequiredNonalphanumericCharacters="5" />

That’s it – increase the length and complexity requirements to the point that it’s highly likely any chosen passwords will be unique, not to mention outside the range of most default cracking patterns. Of course unfortunately, nobody in their right mind is going to demand this degree of complexity because most users don’t have a means of tracking unmemorable passwords. It’s a shame though because that’s pretty much all our cracking problems solved right there.

But let me wrap this up with the following quote from the preface of Bruce Schneier’s Applied Cryptography:

There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files.

This does indeed appear to be the case and unfortunately SHA is now firmly in the former category.

fast hashes are killing our security.

But let’s get a bit of context here – do we really need to be able to generate 4.7 billion password hashes per second? That’s like taking the entire Facebook population of over 900 million and sequentially hashing every single password 5 times every second. And that’s on consumer hardware. No, we don’t need to get anywhere even close to that.

The problem is that algorithms like MD5 and SHA were designed to demonstrate data integrity at high computational speed rather than to provide a password storage mechanism; cryptographic hash functions are not password hash functions. Even if they were “safe” for password storage when designed, MD5 goes back 20 years now so by Moore’s Law we now have processors that are now eight thousand times faster.

There are various approaches for breathing life back into old algorithms; key stretching, for example, where an algorithm which is too fast is “slowed” by repeating it over and over again, perhaps thousands of times. But the guidance around the likes of MD5 and SHA is clear and OWASP summarises it quite succinctly:

General hashing algorithms (eg, MD5, SHA-1/256/512) are not recommended for password storage. Instead an algorithm specifically designed for the purpose should be used.

What we need is a hashing algorithm which was designed from the ground up with speed in mind, not fast speed, but slow speed.
The concept of increasing the effort required to execute the hash function is one that is frequently implemented by key stretching and indeed this is modus operandi of PBKDF2. In fact PBKDF2 may then be applied to an algorithm such as SHA so strictly speaking, SHA is still being used, just not as we know it in its single iteration form. //

the thing about algorithms like these is that they’re adaptive:

Over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt.

Clearly the ability to increase the workload is important if we don’t want to be caught by Moore’s law again in the near future. All we need is a way to integrate this into our existing work.

Desktop: KeePassXC

KeePassXC is a cross-platform desktop app that runs on Linux, Windows, and macOS.

The official KeePass software only targets Windows and runs on Linux via Mono, but looks non-native and clunky. KeePassXC uses the Qt GUI framework and looks nice on all platforms, and is compatible with the same KeePass database files.
Mobile: KeePass2Android Offline

For my Android phone, I'm using Keepass2Android Offline because I don't need cloud sync services, nor do I really want to use them. There is also Keepass2Android that supports cloud services, if you want to sync your database via Dropbox or Google Drive or some other services.
Syncing

To sync my password database between devices, I set up a Syncthing instance on my web server (as the centralized host) and my various devices, including my phone. The password DB itself is managed in a Git repository, so after I make changes, I commit it to git to ensure that there is an 'out-of-band' good copy of the database that doesn't get automatically pushed around between devices. Just in case something happens.

Then I heard about BitWarden. They offered a commercial service (with a free tier) that I could quickly try... they supported all the OSs, mobile and desktop, and browsers that I use... and they release their entire codebase (server and clients) under open source licenses. I tried it, it worked for me, I was sold!

Then I decided I wanted to run my own BitWarden server, rather than use their commercial centralised cloud platform (because, as with LastPass, it's a tempting target). That's when I found out the server of BitWarden was written using Microsoft technologies, C# (yeah, it's mostly open source, but it's dirty to me due to its Microsoft legacy), and MS SQL Server, which is a nasty proprietary dependency (especially given how basic the database requirements for this sort of application are).

So I was devastated that I couldn't set up my own server... until another Free and Open Source Software aficionado pointed me at Daniel Garcia's work! Daniel has implemented a full (unofficial) BitWarden work-alike using a fully FOSS stack: the Rust language, storing data in SQLite, and (quite thoughtfully) re-using other open source licensed components of the BitWarden system that don't have proprietary dependencies, including the website code and layout (which is part of the server).

Daniel's server implementation also unlocks all the "premium" services that BitWarden offers through their hosted service, too... so that's a nice bonus.

Another open source developer, mpasil, has created a "fork" of Daniel's project from which he maintains an up-to-date Docker container on hub.docker.com. Thanks to both Daniel Garcia and mpasil's efforts, it turns out to be quite straightforward to set up your own Docker-based BitWarden-compatible service! Here's how...

Alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

📢 Note: This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues. Please see #1642 for more explanation.

Image is based on Rust implementation of Bitwarden API.

This project is not associated with the Bitwarden project nor 8bit Solutions LLC.

⚠️IMPORTANT⚠️: When using this server, please report any Bitwarden related bug-reports or suggestions here, regardless of whatever clients you are using (mobile, desktop, browser...). DO NOT use the official support channels.

How to Generate Random Passwords?
There are several ways to generate random passwords. In this section, I am going to introduce three of these ways.

1) Using the mkpasswd Command
The easiest method, not only in the three that will be mentioned here, but also among all known random password generation methods. The mkpasswd is a Linux command that generates passwords and can apply them automatically to users. If you can’t locate that command on your Linux box, it might be not installed. To obtain it, install the expect package that contains among many useful tools the mkpasswd command.

The free list contains just the bare list of the top 5,000 words in American English. It is also possible to download other lists that contain the top 20-30 collocates (nearby words) for each of these words -- which provides useful information on word meaning and usage -- as well as to see which words are most common in certain genres (e.g. spoken or academic). It is also possible to download highly accurate lists for the top 10,000, the top 20,000 words, and the top 60,000 words in English, with their top collocates as well.