Just to add for clarity: of course salting is very important and highly useful, but it's only applicable when your generator has the strength of SHA-2. If you're "only" capable of doing MD5 in your head then salting has demonstrable weaknesses.

I understand your position, but I think it has flaws in general applicability.

From a more structured approach: we ask where to draw the randomness (=strength) for your password from. If your generator (boxcar+ID -> f-a2#s:d__x1y) is extremely strong, "boxcar" simply salts the projection and you can keep the ID part very short.
Is having such a complex mental generator preferable to rote memorisation of pseudorandom strings? I guess it might as well be, as the ID part can be as few as 2 characters.

But that's conditional on the strength of the generator, so when recommending a password scheme to your kids and grandmother, how confident are you that they'll not mess up? Case in point: ID=sitename as proposed in the thread branch below, so you get simply boxcarfacebook.com as login password.
I fear with many users "boxcar" would be false security when applied to all their passwords.

This used to be my main password scheme, but I've gradually shifted it out for the other one over the years.
Instead of relying on generating pseudoentropy through a memorised algorithm, it's preferrable to have a randomised and unconnected (but easily memorisable) seed in the first place!
In general, drawing additonal entropy from a highly biased source (fixed string like "boxcar") makes me uneasy (as it should everyone with a CS background).

You're either not understanding what I'm saying or need to try applying the Charity Principle more.

Your local HTML script (a HTML file with JavaScript?) generally can't decide whether to send information to an arbitrary server encrypted or not. For example with a login web page, either the server offers TLS/SSL (the URL starts with https) to your browser, in which case you send your login credentials encrypted, or it doesn't, in which case you can't choose to send them encrypted. What you do locally is of no consequence.

As for the NSA argument, well that's several steps up from people looking at your screen in a crowded room or train. And it necessiates getting rid of the display as soon as possible. And again, throwing clear text passwords onto your drive (like you did in your bash example) is a very bad idea, I hope everyone can agree with that?
That's why it's a terrible example.

Hehe, not "grease money", you give off the impression as if you don't care about reading carefully what your discussion partners have to say ;)
For example, I'm assuming your script can help you remember a password to log into, say, your airline customer account you created two years ago in order to change some bookings. If it could inject it automatically into the field (say through the context menu as a Firefox or Chromium extension) from the clipboard, that'd be a nice bonus, no?

I'm aware that you can write a password vault in bash script :)
But the ggp doesn't show this and instead proposes a highly questionable example as a "quick and simple" solution, which - my point - it's not.

Besides, I don't like the "space before command" because it doesn't default to omitting history entries on zsh (you can set it up of course). And due to being a tiny visual clue... it's almost as inelegant as shooting down the session. The best way to solve this problem is to not even pose the question: don't set up your workflow in a way where you have to work around entering sensitive information on screen while often sitting in different places.

In a world where dictionary attacks weren't as common as they are, you'd be right.
That one particular xkcd always bothered me. Algorithmically, "correcthorsebatterystaple" is as secure as any other 4-token password like "hanx".
Note that "hand" would be a 1-token password and only marginally more secure than only "h" (due to a larger dictionary size, but since its order 1, we're talking about a constant factor).

So typing out the sentence only makes a difference in security if it can't be effectively tokenised to a canonical version, or if the feasible brute force attack lies above the only-first-letter version but below the typed-out version due to dictionary size difference (tokenisation cost). This is not the case with current (and near future) machines for the grandparent's examples.
It does however always make a difference having to type several dozen characters...

It's usually not your choice whether or not to send the password in clear text over the internet, but I strongly recommend simply not using services that don't offer encryption.
But that has nothing to do with my previous comment... again: I don't want my password to be visible on screen (neither the "salt" one, nor the resulting hashed password). And if it gets saved anywhere on disk in clear text (like it does with your bash one-liner), even worse! You shouldn't present such a bad example as a viable method only to mention in a follow-up comment that you have something actually usable.
I assume your JavaScript (which presumably is geared to web logins?) shows a "password" dialog (the input characters starred) and then enters the result into the password entry field on your current web page? Is it Greasemonkey script or a plugin?

Good, but I'm not sure why you bring that up. The topic is how to teach people to remember passwords to arbitrary (website among others) logins efficiently.

LastPass, SeaHorse and all the other vaults are good options with only few drawbacks (for example that you have to have the software with you). A solid mental scheme as I presented further above is another option.

Hmm, I strongly dislike the idea of sitting in a public place and typing my "salt password" visibly into a prompt (especially if it litters the bash history), and then also getting the resulting login password in clear text.

I guess you're not proposing to remember those pseudorandom login passwords, because that's a pain for dozens of accounts (and you could then simply use any input or even sites like http://www.passwordgenerator.e...)

I've been using this scheme (base word + something connected to what the service does, usually in leetspeak) for about 15 years now to help me remember passwords for obscure/rarely used accounts.
The most important insight is: use it ONLY for unimportant/throwaway stuff and PLEASE stop recommending it as a general method to people.
I have more than three dozen accounts and passwords. At some point one of those WILL be breached, probably without you ever being aware of it, and without any blame on your side. It happens even to the likes of Amazon. And then what? Anybody who takes more than 5 seconds to look at your password, or even a malicious system maintainer who grabs passwords at login, will be in a position where your passwords are just 3-4 token variations (and we're all are aware how quickly you can break 4 character passwords even by hand).
Sure, it's not very vulnerable to automation (unless somebody decides that enough people are using this and couples it to pattern matching with the service and identified base words as input, and a brute forcer), but once a human mind sets you as a target, your online world is SOL.

IMO the best password scheme is still 8+ tokens (letters like 'a', words like "house", numbers like 123) that have absolutely NO CONNECTION to the service that offers the account or to publicly available information about you.
A good pattern (among many others) is to draw from an unrelated memorable sentence at the time you are creating the account. For example if you joined Slashdot last month while listening to the news, you may have thought "Hopefully the Russian annexation of Crimea doesn't start a war" and take the first letter of every word: "HtRaoCdsaw".
Or for a shorter sentence ("Let's not have a war again") every second word: "notaagain", but note that these are only 3 tokens, i.e. as bad as a 3 character password, so you have to spice it up through punctuation and leetspeak, according to a personal scheme of yours. But the important part is that when someone discovers and understands your scheme by looking at a leaked password, they will still have no chance of cracking your other accounts because the base sentence is unrelated. And since you picked something memorable, the mnemonic hook will help you remember it for years.

Hmm, so let me go ad absurdum here for a moment...

You witness someone falling into a big water tank, the rim is just out of arms reach and it becomes obvious that person can't swim. Nobody else is around, so you're expected to walk over and give him a hand, no big deal. But you refuse, claiming that it's too much of an effort to pull up a grown person and you'd probably experience some strain pain, and might get wet... all such things that put stress/pain on your body. So you don't do it, the person drowns, you claim innocence before the law because of the sovereignty of your own body.

Regardless of the "asshole-level" of your actions, in my country (Switzerland) you'd go to jail for Failure to Rescue, which I and obviously my fellow citizens think is correct. So where do you draw the line between this example and yours?

Please elaborate a bit more on your first sentence. I don't live there, so I have to rely on Wikipedia etc., but the population of Crimea is around 2 million, out of which 58% (1.16m) are Russians and 12% (0.24m) are Tatars, with 24% Ukraininans.
If 100% of Sevastopol (population of 380'000) were Russian, that still leaves 780'000 Russians vs 240'000 Tatars for the rest of Crimea. I'd say if anything, Crimea on the whole is ethnically Russian.

Maybe you're referring to the historical development. But I don't see how 3 centuries of Tatar rule take precedence over 4 centuries of Bulgarian rule, 2 centuries of Kievan Rus' rule (both slavic) and all the others (Greeks, Goths, Huns, ....) before the Tatars arrived in the 15th century. And for the Russian rule since the 18th century, afaict the whole pretext for the subjugation was that the Crimea was slavic lands.

Your example in the first paragraph isn't really applicable: imagine if the majority of Iraq's population were Americans... completely different context.

Also, keep in mind that the USA had several opportunities to resolve the WMD inspection problem (like allowing the EU to chose the inspectors) but they always chose the escalating "my way or the highway" option. IMO it's pretty hard to argue that the primary reason for the Iraq invasion was not oil and financial imperialism. Just look at who controls all of Iraq's oil exports right now.

Not sure how that works.
If somebody just fixes a handful of characters, they aren't eligible for copyright in either the Apache or Linux code... so that sort of drive-by patchers aren't relevant for the discussion.

But if I "drive-by contribute" nontrivial code to someone with Apache commit access, that code is still under my copyright and the committer is not allowed to push it under the CLA unless I agree to the CLA as well (or resign my copyright to the committer). Which brings us back to square one.

Unless I'm completely missing something. Please enlighten me.

Got a raging one for Steam? Steam is hardly original, except maybe on Windows.

No real App Store? Are you aware that you can buy proprietary software, music, etc. in the Software Center on Ubuntu, Mint and Suse right now? Sure, it's not universal across all distros, but Fedora and Debian reject proprietary offerings on principle (and still have tens of thousands of non-proprietary programs in their sofware managers) and the rest are irrelevant in terms of market share, so Steam for Linux follows the same distribution curve.

Steam has friend lists and achievement notifications, but that's not exactly needed for an application store... while both APT and RPM are technically vastly superior (Steam doesn't even support delta updates, version hold-ups, downgrades or concurrent dependency resolution) and have been around quite a bit longer.

However, I'm pretty confident it'll find a niche because of the built-in social networking, where it has to compete with Desura. But it doesn't "standardise Linux for developers" except in the packaging (which is somewhat around 1% of a porting effort), doesn't offer "stable binary APIs" (that'd be drivers, kernel and middleware/engines) and can't hope to improve on the present library version management.

That said, yeah, it's nice to have one more option!
Sorry if I've damped your enthusiasm, no offense meant, but your comment struck me as starry-eyed ;)

I've served as field transmission soldier and command staffer in our military for 10 months... reasonable is not exactly a fitting adjective. There's no enemy (except for jokingly mentioning Lichtenstein etc.) we could hold up against, and our main defensive strategy (still basically the Reduit/Bison plan) is just WTF-ish: fully abandon the ~20 biggest cities, most of the population, all industry, nearly all agriculture and hole up in the alps waging guerilla warfare.

We're a country of 8 million and had a military strength of ~0.8 million 30 years ago (keep in mind it's a militia system, that's basically 800k Ueli's [=Joe Public] with a rifle). After the reductions are completed, we'll have roughly 80k militia by 2020. If you want to use the word "reasonable", the continuation of this trend would be a good subject to apply it on.

The military expenses remain mainly penis enlargements for traditionalists, but as has been the case since even long before the French invasion, we absolutely have to rely on allies with actually large/modern militaries (probably northern/western Europe) to bail us out should pretty much any nontrivial invader decide to give it a go.

Diplomacy is our best defensive weapon and has been sufficient for the last two centuries (also: money). Plus there's not even a remote threat on the horizon except for "The Terrorists", though tanks and artillery have not exactly proven effective against those.

Since it would be patently stupid for the Syrian regime to deploy chemical weapons given the current situation, and we can agree that Assad is somewhat intelligent (regardless of him being an asshole), wouldn't Occam's Razor dictate that the CIA had clandestine agents deploy the weapons against the Syrians in order to facilitate a strike?
They have the intelligence, agents, capability and most of all motivation. It's against some foreign population, which has been shown they don't really care about. At a very convenient point in time for the USA.

The CIA or Mossad are the most likely candidate, so that would actually be the simplest explanation, no?

</DevilsAdvocate>