So there exists a browser extension to implement what you desire, it is called HashPass.

However, if you use such a strategy, you *still* must have a password resilient to dictionary attacks. The attack scenario it provides *some* protection against is if you use a site that has poor security storage policies, without your knowledge (e.g. stored in clear text). The idea is that if such a crappy site gets compromised, it's view of plain text password is the end result of your client side salt, which now can be run against a dictionary attack. It basically is ensuring that *someone* is doing a secure hashing strategy that would reasonably protect a strong password in the manner the server side *should* be doing anyway.

If an otherwise secure site adds what you describe, it would do nothing to enhance security. If your password is *truly* strong and they employ proper salting and one way hash strategy (scrypt, PBKDF with adequate passes, what have you), then a leak of their password database is not actually that big a risk. If your password is weak, then the salting strategy client side doesn't add anything, as they could modify their brute force attack to do the client transform in a trivial fashion, and they can work their way back to the password you *really* use.

Note I *think* he's saying that whatever string the client ultimately sends to the server should still be one-way crypted and salted in the usual way. Meaning a compromise of the database still has reasonable protection.

He wants something to automagically take his password and make it unique per site so he doesn't have to remember them all. Note that this is what things like the extension Hashpass do, generate a site specific password derived from your master password and transformed for the site.

Of course, all this said, the dictionary attack required involves just adding that transform, hence that strategy only helps if you are afraid the site has a plaintext password database or unsalted crypts, and your password would be secure against dictionary attacks offline. It makes zero sense as part of a websites arsenal against attacks.

Note that this *also* would be a sign of an incompetent site. Password databases should be impervious to rainbow tables. Also, a GPU would not really be that useful for a rainbow table. A rainbow table is a precomputed table of hashes, meaning it's a straight lookup rather than actually having to perform the hash calculation. A competent site would have a sufficiently long random salt incorporated to render rainbow table impossible.

Of course, dictionary attacks against offline database are still a problem, and so it would be good if your password is not likely in the first 100 trillion or so guesses a system would make (which on a decently secured password database would buy you about a year of time against 8 full time GTX 1080s working on your password and your password alone).

No, far more effective would be minimum password (phrase) length. People thinking 8 characters are fine as long as it is leet-speak is a problem. The way most people use uppercase, numbers, and symbols make the dictionaries a little more tedious, but not *that* much more so.

Sure, the most secure approach is totally random, but if people insist on it being human friendly, number of characters is the key point to emphasize.

Passing on mitochondrial DNA doesn't really count.

Yes, a lot of work went in, but ultimately, all of the *significant* genetic material came from two parents. Passing on your mitochondrial DNA doesn't do anything to really shape your offspring (unless your mitochondrial DNA is just *really* messed up). Now if the donor egg somehow had defective Mitocondrial DNA, ok, this is at least somewhat useful.

But pretending this offspring has three equally biological parents is disingenuous.

Rather than local, I meant remote, but same house.

At least with emby, local rips are instant. I had a bear of a time with Plex Media server performance, so I migrated. That was a long time ago though.

I used to use plex. I've moved to emby.

Under linux, you might as well give up and run it under docker as they are very messy about their depedencies, but at least that's not too complicated.

For most places and efficient low cost configs, I'd say maybe 30-40/year in energy cost.

The upload bandwidth is killer. The performance of accessing the media is terrible (when I access a local rip, it's super high quality and *instant* seeking, versus streams from netflix and the like.

Actually, I'd say it would be more of a nightmare. Here we have the devils we know. In that scenario, it would be hellish even *knowing* what can't handle things.

Every hop in the network not being certain whether the next hop could or could not handle the conversation would be a nightmare in the making.

It seems funny, because that *ultimately* is the reality of IPv6.

The difference is that in the above scheme, *knowing* whether a hop in the network could or could not do 'big addresses' would be more difficult. With IPv6, it allows things to be very clearly delineated whether the communication is IPv6 capable or not.

The biggest obstacle to IPv6 was the stubborn resistance to any form of NAT. That IPv6 should be all or nothing. The piece needed to make IPv6-only *clients* possible was carrier grade NAT64. Yes, on the server and as a carrier, you need IPv4 *and* IPv6, but the vast bulk of endpoints can be IPv6-only now, taking the pressure off of IPv4. Of course this would have been nice to do a decade ago instead of the last two years or so, so that new servers could have a more comfortable time getting IPv4.

I personally would rather *not* have crypto at the IP or TCP layer. Reason being is that in practical terms, updates *must* be delivered through kernel updates. Given the nature of crypto updates, I'd much rather have librariers in userspace be the channel for updates.

I don't think I need a big conspiracy about AH/ESP. They were really awkward approaches, and largely redundant with higher layer strategies.

The issues with DNS/DNSSEC are more reasonably addressed in the DNS layer. There is a lack of will to tackle that problem, but that's the same lack of will that would make implementing at a lower layer impractical as well.

When I pull up my cell phone ip information, it's IPv6.

Now that there's carrier-grade nat to allow ipv6-only endpoints to speak to ipv4-only hosts, it *finally* is plausible to offer most mobile/residential ipv6-only. So a lot of the people who are ipv6-only are precisely the ones that would never realize it.

For enterprise networks and internal networks, those are ipv4 and likely to stay ipv4-only (which is a bummer for software development, because IPv4/IPv6 agnostic code is still relatively rare, since there's so many subtle bugs trying to use AF_INET6 for both, and it's more complicated to have both AF_INET and AF_INET6 addresses).

It's an inefficiency that is very intentional.

The software industry realized that for a lot of their users, they couldn't extract upgrade licenses from customers readily because they had already done *too* good a job. Functionality wise, a lot of people don't need anything newer than Photoshop 6 (released 16 years ago). A lot of people could use Office 97. Of course some things have slowly evolved technology wise that *ultimately makes people need updates and there's some forced updates (e.g. fun incompatibilities in ms office formats), In general though, update revenue became a big uncertainty.

So the solution is to switch to rental models, subscriptions, et al. Licenses that terminate when you stop paying, rather than the 'old' way of transactional purchase that has indefinite usage rights.

Now a software company can much more efficiently milk their userbase for money without really having to figure out meaningful value add beyond what they already do.