Or you could tattoo the passwords onto your fingertips. Say, that way we could combine password + biomorphic verification into one unified system! Consider that a proposal, please. (Where does one register all these proposals to make them official, anyway?)
Well, not always. It is a possibility that the limitation could be to avoid any potential buffer overflow attack by somebody who tries to stuff megabytes of data into the password field. I’d say that the limit should be something like 64 characters, but it’s also possible that an older password hashing function that’s running client-side, when it was designed several years ago may not have been able to handle really long password strings fast enough (at the time). I’m not trying to excuse not allowing reasonably long passwords, but it’s not unreasonable for there to be some limit on what can be entered into the field. Especially a key-stretching password hashing function like PBKDF2 running 100,100 iterations.
2 Likes
Definitely a possibility, but unless this software was designed back in the 80’s, when RAM was an expensive commodity, the buffer sizes should be much larger. If this was the 90’s, I’d say make it a 8-bit length (up to 255 bytes). Today, I’d make it a 16-bit length (64K bytes). This is large enough for any legitimate password and can still prevent a buffer-overrun attack from causing dynamic allocations of megabytes.
Back in the old days when DES was used as the hash function (Unix DESCRYPT encrypts a well-known string (typically a buffer of all-zeros) using your password as the key in order to generate hashes), an 8 character limit made sense, because that’s all the cipher would use anyway (56-bit key, consisting of 8 7-bit characters). But that was a long long time ago, and DES was never considered terribly secure, given its short key length.
3DES was marginally better (run DES encryption 3 times with 3 different keys), since the key length could go up to 168 bits (24 7-bit characters). But even that was never considered very secure.
Anything remotely recent, however, should be using a much better hash function MD5 (no longer considered secure) was published in 1992. SHA-1 (also no longer considered secure) was published in 1994. SHA-2 (6 variants) is considered secure and was published in 2001. SHA-3 was published in 2016. None of these impose any length limits when used to hash a password - they will accept any arbitrary size document (typically a password with salt) and generate a fixed-length hash from it.
Given the fact that solid implementations of SHA-2 have been bundled with Unix systems (including macOS) for decades, there is really no good reason for someone designing a system to use anything less. And you would need to be maintaining some incredibly old software if you can’t even use MD5 (which may still be quite useful for password hashing, even though it has been cracked and is therefore not safe for document authentication).
Yes, it could be aggravating to upgrade a system from a bad hash to a better one, since you would need to force a password-reset on every user, but that’s still a lot better than dealing with a data breach (which will require the same password-reset, plus the impossible task of trying to recover from the damage from the attack).
1 Like
Absolutely. Despite my posting in this topic, I think rolling your own password management solution is insaneinfeasible for most people. If I were to use the five-word approach, it would be for accounts where I have to type the password myself sometimes, and everything else would be long and random in a password manager.
Right, but as I said, that was a trivial example. It takes no imagination to come up with five words that aren’t obviously related (not that it seems likely that a dictionary attack would try just proper names anyway). If five Diceware words supposedly provide high entropy, I don’t see why any other five more memorable words wouldn’t.
2 Likes
Well, I said I’d be derided for suggesting this. Or maybe I should just be flattered that you don’t consider me “most people”. 
Diceware approach has you rolling dice and picking random words from their list?
My guess is to ensure a random choice of the words…vice a user that might pick couch if they just picked words and thus some passwords would be a bit similar. I just try not to pick words I’ve used before…look around the house and see a painting of mountains and then riff off of that.
I am teaching Python remotely to a teenager (and learning it myself to stay ahead of him), and one of our projects is a password generator with options for special characters, etc. I could see someone rolling their own. Securing the file would stump me at this point. I wonder how secure a disk image would be for storing a file of passwords? Once unlocked, Python could read the passwords into memory and provide options for finding the passwords needed. 
There are two parts to the diceware question, randomly choosing words and why real dice?
The choosing words part has mostly been answered–there are limited words that people will choose spontaneously, so when need 100+ passwords, there will be a lot of overlap, and that will also make them harder to remember. I’ll add that even if you have a perfect memory of what you’ve ever said online, you have no idea of what other people who know you have said online. I doubt that you have perfect memory of everything you’ve ever said in person to others and you can’t know everything they’ve said online. And there’s little chance you’d know that three of your secret crushes have posted that they suspect that you had a secret crush on them.
If you’re actually targeted, it’s not hard to find your old year books and class lists k-12 through university, membership lists for any organizations you’ve belonged to, records of what cars you’ve had, where you’ve lived, etc. and use all of that data, expanding it to vocabularies related to your hobbies and occupations. (I sadly don’t use unpopular invertebrate words in my pass phrases…)
As for using real dice, that’s because computer randomness isn’t very random compared to physical phenomenon, including real (fair!) dice. It’s better than it used to be–algorithms have improved, seeding has improved, but there are real limits. Worse, there continue to be problems with flaws in algorithms, both logical and implementation. Ah, just use the well-vetted open source libraries! But few of those have ever actually been well-vetted, and they’re currently under increasing attack from supply side malware. Randomness is hard, cryptography is hard, programming is hard, knowing what’s actually in code libraries is hard, and there are many ways to subvert all of them in bulk. It’s quite difficult to subvert your dice.
My very favorite random number generator is the wall of lava lamps in one of Cloudflare’s offices:
https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/
Password length: there have been quite a few cases (including bank of america) where web servers will truncate the long password you use, e.g. they’ll let you use a 30 character password, but only the first 8 are used.
At least you can leverage bad password rules to annoy scammers! aka Password Purgatory:
You can play in purgatory, too:
“But this also applies to any employee of a corporation. You may not be in any way famous, but if (for example) you work in the IT department for a business that has government contracts”
University systems and people are under constant attack, from ssh dictionary attacks through fairly sophisticated phishing. It’s improved a fair bit with border walls such as TippingPoint, but universities have many things that attackers crave: lots of network throughput (valuable for spam and DOS vendors to sell), lots of minimally secured computers for cryptocurrency mining, DOS attacks, and entry points into higher value computers, plus intellectual property to steal.
Even if someone is ‘just’ a humanities undergrad targeting is possible, so keep those shields up.
2 Likes
I remember when this was a college experiment. It was later discovered that it works just as well if you leave the lens cap on the camera - the noise in the signal from the sensor was random enough to work. The lava lamp just makes it look cool when publishing the paper.
No disagreement here, but I think you missed my point.
I’m referring to people who are likely to be personally targeted - where an attacker may perform background checks and do other research in order to determine a way to exfiltrate information from the computer systems he has access to.
These are people who you would likely learn about when researching material about what you want to steal.
For instance, if you wanted to steal schematics from Apple, you would first get a list of the company officers. Then the key project leads (many of whom are known, via media events and published papers). Then individual engineers working on the project (who may be hard to discover - companies don’t generally publish the company contact lists). But you wouldn’t blindly go after everybody with an @apple.com email address, because most wouldn’t have access to what you want and this kind of research is expensive and time-consuming.
Similarly for a university. An attacker would want to go after the people in IT running the computer systems and professors running the projects under attack, and the students working on those projects (who would be known if their names are on published papers).
But going after everybody at the university (just like everybody at a corporation) would be far too broad for personalized attacks. These people still need to be careful with security, but it is unlikely that anyone will research their personal lives as a part of the attack - they will resort to more generic mechanisms (like password cracking, phishing, malware) and probably not go beyond that.
Password generator for what purpose?
If you’re talking about an authentication mechanism for a service, then you don’t want that service storing the password at all. Generate a hash from it (using a secure algorithm and salt), and store the hash. Then when a user requests access, you hash what he provides and compare the hash against the stored hash, granting access if they match.
If you’re talking about a password manager app, where you need the plaintext in order to use it on a web form (or other login mechanism), then you clearly need to store it using reversible encryption (not a hash). There are several ways to do this.
One of the simplest ways is to use a normal database, but store encrypted passwords. Use a reasonably secure algorithm (e.g. AES). Encrypt the password and store the cyphertext. When you need to read the password back, load the cyphertext from the database and decrypt it in memory.
Use a master password in conjunction with salt to generate the key used to drive the encryption. So someone getting the database won’t be able to use the passwords without knowing the master password (which the user should provide as a part of opening the database).
But note that the mere fact that you are keeping the plaintext password in memory (even briefly) means that an attacker running software on the computer (e.g. via malware) could read your application’s memory space and get that password. To protect against this, different operating systems and hardware platforms may provide secure memory features (where only the process that allocated the memory can access it), but that solution will depend greatly on what your platform actually makes available.
In other words, reasonably-safe security isn’t hard to do. But perfect security is virtually impossible. So you always need to consider your requirements in order to determine what is “good enough” for your project.
A disk image might work, but the problem there is that you need to mount that image in order to access it. And while it’s mounted, any process with suitable permissions from the OS (e.g. malware running as the same user that is accessing the image) can also read the contents. It’s not something I would trust.
You could keep an in-memory database of all the passwords and encrypt the data before saving it to the file system (again using a secure cipher and a key generated from a master password). That would work better than the disk image. The problem here is that once you’ve loaded and decrypted the contents, you now have all the passwords in memory. Which may be a vulnerability (see above). And this would be a more tempting (and easier) target than just storing one plaintext password, since someone scanning your process’s memory could probably find the database without too much work.
Of course, since this is just a learning activity, it may be best to try all of the above (and maybe a few more) and then have a discussion about the pros and cons of each approach.
It might also be interesting to try different ciphers for the encryption, starting with the trival (e.g. a Caesar cipher) and working up through other algorithms, writing brute-force test programs that try to hack each one, so you can see the effects of different ciphers, keys and salts.
It might also be interesting to look at some well-known ciphers like DES and RSA to see how these technologies work. Maybe try to implement some of the simpler ones in order to show how while they might not be conceptually difficult, making a solid implementation can be very difficult - as a part of a discussion about why software developers should never try to roll their own cryptography, but should always use well-tested and well-supported third-party (commercial or open source) solutions.
(FWIW, when I was in college, we had a homework assignment to implement the RSA algorithm. We used fairly small prime numbers (e.g. 13 and 17) for key generation, which is insecure, but can be used to produce keys that you can process by hand on calculators, and which don’t require specialized math libraries to implement. It was a difficult, but fun assignment.)
2 Likes
Here’s to the crazy ones!
Yeah, I think this gets back to whether you’re actually trying to create passwords for all your services. I just can’t see hardly anyone successfully creating, remembering, and typing 100+ passwords. I’d do this for 10-15 at most.
1 Like
FWIW, I have passwords for about 300 services. I’ve created them all by hand and most (including all of the sites that matter) are pretty secure.
But I definitely don’t have them all memorized. They’re stored in a text file on my desktop Mac (NOT mirrored to any cloud service!) and the ones I use most often are stored in Firefox’s built-in password manager (which is mirrored to all of my Firefox installations via Firefox Sync).
When I travel, I may bring the text file with me on my laptop, but when I do, I keep it in an encrypted disk-image (whose password I do not store in the keychain), to protect against the possibility that the computer might get stolen.
1 Like
Re: Rolling your own password management solution
“Laziness is the mother of invention” – Anon
Add to that my marvelously dyslexic typing, I concluded that a good Password Manager is mandatory for me.
Since I do not have the security programming chops to create and maintain a password manager for multiple physical and OS instances, exacerbated by lack of time and ambition, a Subscription to 1Password or the like became an inescapable conclusion.
Your business/personal case may differ.
I used to use the FF password manager to store logins, for years… it was very convenient, similar to the Mac’s own keychain (but less buggy, as I recall)… then I got nervous about it, and stopped using it. But I don’t remember why I got nervous about it. What is your impression of its security? Has anybody seriously analyzed what it’s doing under the hood? Does it upload anything to Mozilla’s servers (or anywhere else) for “syncing” purposes?
More cloud vaults hacked!
A major tech site has an article about two major new cloud-service breaches – one of them a security-oriented service, though not a password manager – which they lump in with the LastPass breaches. They also suggest a spillover effect is possible, since so many of these kinds of services use each other’s services for various things.
The range of user comments/opinions are kind of similar to those here, in a way, but overall it’s shorter (so far) than this thread. Check it out.
What the ultimate authority on encryption says…
The two most credible and expert security voices in the world, IMHO, are the encryption expert Bruce Schneier, and the computer-security journalist Brian Krebs. (Each have their own website.)
You’ll find a very brief summary of Schneier’s attitude towards cloud-based password managers here. He mentions his own security project, which I haven’t looked into yet… but he also says:
" My particular choices about security and risk is to only store passwords on my computer—not on my phone—and not to put anything in the cloud. In my way of thinking, that reduces the risks of a password manager considerably. Yes, there are losses in convenience."
Essentially the same as what I’ve been saying here, isn’t it? (Although I don’t have any security expertise and don’t claim any, just a gut feeling.)
3 Likes
Yes, we are interested in creating a password manager — thanks for a great road map. 
The companies are chat service Slack and software testing and delivery company CircleCI.
1 Like
If you don’t enable the Firefox Sync feature, then the database is stored locally in your profile (logins.json) and it never leaves your computer. Each record in there looks like:
{"id":6,
"hostname":"https://www.example.com",
"httpRealm":null,
"formSubmitURL":"https://www.example.com",
"usernameField":"...",
"passwordField":"...",
"encryptedUsername":"....",
"encryptedPassword":"....",
"guid":"{00000000-1111-2222-3333-444444444444}",
"encType":1,
"timeCreated":1308628396205,
"timeLastUsed":1654022880149,
"timePasswordChanged":1343726148177,
"timesUsed":13},
The user names and passwords are encrypted. I don’t know where the key comes from, but appears to be locally-generated and different on each computer, since the encrypted strings are different on different computers, even after they have been sync’ed together.
If you configure a primary password for your passwords, then Firefox will not allow access to the contents without the password. Without this password, anyone running Firefox can go to the password manager (in the app) and view the contents.
I noticed that logins.json file does not change when a primary password is enabled, so I suspect that under the covers, the system creates a random encryption key and stores it somewhere in your profile, with the primary password encrypting that key. But I’m not sure.
If you enable Firefox Sync, then the data is end-to-end encrypted using a key derived from your Firefox account password. (So make sure that that one is particularly secure!) The encrypted database is stored on FF’s cloud server. Login credentials to that server are authentication tokens cryptographically derived from your account password - so they never receive your actual password and (they claim) it is impossible to derive the encryption key from the authentication token.
Anyone can configure Firefox to sync your passwords, but they would need your FF account password to download and decrypt the file. And if you have 2FA enabled on your FF account, they’ll also need that in order to initiate the download.
I assume the data encrypted by the sync service contains the plaintext user IDs and passwords, since the locally-stored versions seem to use different keys on different computers, even after they have been sync’ed.
As for an analysis of how secure this system is, I’ll leave that to others, but here are a bunch of articles that explain how they say it works, along with an audit report from 2017.
See also:
- How Firefox securely saves passwords | Mozilla Support
- Where are my logins stored? | Firefox Help
- Use a Primary Password to protect stored logins and passwords | Firefox Help
- Master password - MozillaZine Knowledge Base
- Private by Design: How we built Firefox Sync - Mozilla Hacks - the Web developer blog
- A Security Audit of Firefox Accounts - Mozilla Security Blog
3 Likes