When you hash the password on the client, especially (and quite dangerously) if you're using a known and/or easily guessable salt, the hash you transmit to the server simply becomes a markedly weaker authentication token
Demonstrably untrue and indicative of someone who doesn't understand the first thing about hashing algorithms. I'm not saying you can dump it into a single iteration of your command line version of SHA and automagically get something that works. It has to be intelligently constructed, properly utilize all input, and produce output that significantly exceeds the size of the input. If the password field has a maximum, let the hash output be twice that size. Are you still going to argue that "markedly weakens" it? My gut says that if you used a 1:1 algorithm stage in there somewhere that it wouldn't even need to be that big, but I haven't had time to research this in detail. I'm not an expert; I just am not a moron about these things.
I'm sorry if this is rude but I've been more than patient up until now: You people are fucking clueless. You apparently think that just because you've set up a few HTTPS webservers and you use these shitty command line things that you call "hashes" that somehow makes you an expert on information theory. *I* don't claim to be an expert, but I'm also not wrong.
Once the token arrives at the server, per your scheme it would be rehashed, but with what salt? Server side salt reuse here yields the same concerns,
Server should use random salt; sorry if I didn't make that clear. The static salt is for client side only. Random salt for client is either a secret keyfile (undesirable for usability reasons) or it's transmitted from the server, which is makes it just a pointless redundancy with the server-side hash. You *could* have both sides use random salt, I guess. It wouldn't hurt. I was just trying to keep things simpler than that. Random salt that is broadcast is obviously less desirable than random salt that is kept hidden on the server.
I appreciate the effort you're making but I really would like for us to be on the same page before I make any further effort to research and provide you with a more detailed spec of what I'm thinking of here, if indeed that is truly necessary. Several of you guys are misstating what I'm advocating and also asserting blatant falsehoods about hashes worsening security.
Repeatedly conceded. I'm not a professional cryptographer.
your proposal is not backwards compatible (Javascriptless clients)
That's fine--all sites that work properly without javascript are exempt. OK? That still leaves us with 90%+ of the web, which does require JS. Also, I further specified that I'd prefer to see this as a browser function akin to HTTPS.
less effort would be needed from the coder by just doing security properly in the first place.
Unfortunately, we've seen repeated proof that you people cannot be trusted to do it properly on your end. With client-side hashing, strong pressure can be brought to bear on people who aren't using it, companies can prevent their employees from visiting insecure sites, browsers can generate warnings about insecure password fields, etc. They should still use server-side hashing, but if they lie about it then we at least will have the protections that client-side offers.
Furthermore, you've shown in previous threads that you're willing to dismiss any arguments against your proposal.
Citation needed. I've endeavored to address every single objection raise, although so far they've been fairly boneheaded and impolite objections so you shouldn't expect my responses to be candy-coated.
The simplest way to make things secure is by using HTTPS and a store_database(hash($password || $salt)) call in the server code.
You. assholes. cannot. be. trusted. I'm not idly saying this! I've lost two accounts with a very long, unbruteforceable password apparently due to plaintext database storage being used. I've already had one AC poster, ostensibly a slashdot regular working at a major company, talking at length about how they are using plaintext storage and have refused repeated calls to implement salted hashing.
C&P: No payment for fools who don't understand how to use hashes properly.
In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
No payment for fools who don't understand how to use hashes properly.
In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
P.S. As I noted elsewhere, you've probably hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--you guys have a very limited understanding of how hashing can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.
2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic. In particular, the hash should be able to handle on par with the maximum password length and the hash output should exceed the size of the input, possibly greatly exceed it.
3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)
4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that a secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.
You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.
1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.
2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic.
3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)
4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.
You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.
And in fact, I'd argue that with any JS-based solution an average user couldn't either
But security bulletins could be posted. Companies could prevent people from visiting sites that refuse to use client-side hashing. Browsers could warn you with dire-sounding popups. Pressure could be brought to bear. As I've already described, it doesn't replace server-side hashing but if they are dumbasses about it then it at least mitigates some of the damage done by a lack of server-side hashing.
It's only "not easy" in the sense that any change requires work. It's not something that requires much more CPU work than what HTTPS already requires. It's not something that would take more than a couple weeks to set up, test and deploy. Do you disagree?
Hitler meant it. Trump doesn't. Trump is an amoral twat more concerned with popularity. Saying that he'll deport 11 million people or whatever it was, doesn't make it so. The next jerkoff to come along might mean it, but I don't think a Trump presidency makes that more likely (actually, probably very slightly less likely.)
That said, I'm not pro-Trump for reasons already outlined.
This is one decent upside from my perspective: anything that accelerates GNOME's downfall or at least decreases their market share is a good thing. Their devs badly need to learn some humility and perspective. They not only appear to believe they can be the next Apple, but they believe that the key to doing so is to treat its users like dirt, not realizing that this was an unnecessary side effect and not a causative agent in Apple's success.
This might have carried some weight in the Bush years, but the fact is Obama and the rest of the democrats did very little to undo the most egregious damage.
Trump is an outsider. His damage from recklessness (if indeed he maintains the same persona--more on this momentarily) is less likely to lead down the road to dictatorship than Hillary. Reports of his Hitlerishness have been greatly, greatly exaggerated and do much to alienate many people who might otherwise have been talked out of a Trump vote. Calling Trump the next Hitler has never swayed the opinion of a single person who was on the fence. If you don't understand this, then you don't understand anything.
That said, he's far too stupid and lazy to actually inflict any real damage of that sort. He's going to end up as a puppet of the Republicans, just as bad as Bush ever was (so, there's *that* kind of damage), except he'll occasionally do something especially wacky (but entirely inconsequential) just 'prove' that he's an outsider. So, this likely outcome rather cancels my above analysis. He's not worth voting for precisely because he is not likely to burn anything down, and the Republican establishment is a great deal more odious than the Democratic establishment.
But I'm not a fan of either, so... please vote Johnson or Stein. It doesn't matter which. It doesn't matter; it's not about them winning, it's about laying the foundation for the breakup, or at least the shakeup, of the two-party system. Don't stay at home, and for fuck's sake don't vote for the lesser of two evils. The best hope we have of burning anything to the ground is by not voting for either party, period.
The fact that you think this about ego really says it all. You think that I think that this is some brilliant, complex, end-all and be-all solution. I explicitly said it wasn't. It isn't a credit to my intellect, not in the slightest. It's a 'credit' to yahoo's stupidity that they didn't do this. And it's a credit to yours that you've posted like what, perhaps ten pointlessly hand-waving posts of zero content, arguing that my ideas are broken because you have more than ten years of experience, that's why!
I can't even begin to describe how much joy it brings me to hear you spout such idiocy. Please, do it again.
We didn't have a unprivileged LXC, vt-x or vt-d in 2004. Compartmentalization is the foundation of good computing practices; hell, it's what UNIX was famous for. It's a way of bootstrapping microkernel-like structures into a monolithic system, which might be ass-backwards but it can work pretty damn well.
Also, as I've said before in response to this very subject, the fact that something has been done before has nothing to do with whether or not it'll become popular now. Lisp was doing things in the 1970s that we didn't really see again in other mainstream programming languages until the 2000s. The Amiga was a bit ahead of its time as well. Sometimes these things do take time.
You should be careful with this. I don't disagree at all with the broader criticism of Red Hat's politicking; in fact in many ways I think the criticism has been far too limited. For example, their involvement in GNOME is inexcusable given not just the attitudes of the devs but also the explicit stated goals of the project.
But the longer you deny that there is any point whatsoever to systemd, the more damage you do to your cause, because it *does* do some stuff that it tricky to do in SysV. Want to change peoples' minds? Show them how to do something similar in OpenRC, or explain some other workaround. Emphasizing only the bad and pretending that the good doesn't exist usually does not end well, even if the good is overwhelmingly outweighed by the bad.
For example: containers are not fucking niche usage cases. Containers are the future of secure, robust, high performance computing. In the future, they will be widely used regardless of whether or not the user realizes that they are being used. Calling them niches that most users don't care about makes me think that he is a clueless, dogmatic fool. It makes me less likely to pay much attention to anything else he says.
You've no idea. This isn't about ego at all; I simply enjoy watching people make asses of themselves. Feel free to call me a sadist, if that makes you feel any better.
And it turns out, I can do your arguing for you! I found another crypto "expert" that I'm IMing at the moment and just like you he threw a hissy fit at first, but after 45 minutes he was forced to concede every single one of my core claims, while still claiming that it would never work in practice because they would never do it, which isn't an argument I find very compelling.
But your problem, I believe, is a psychological aversion to offline attacks. You like shit to stay online where things can be drastically limited and even CAPTCHAs can be used. Fair enough: ok then, if you're paranoid then you're allowed to change your password after a break, even if it was a very strong password. Who said you couldn't? Security is about roadblocks, not absolutes. And you can put a huge roadblock up by applying a good hash to a good password, a roadblock that shouldn't be breakable by any world power today in a reasonable time frame. But, then, I might be slightly more tenacious than most; my FDE password is over 100 characters.
Speaking of good hashes, you also may have an unhealthy mental picture of the purpose and limitations of hashing algorithms. In reality, collisions don't have to be a problem if you don't let them be. At first, the guy I'm talking to wanted to argue like crazy that collisions were always inevitable until I started pointing out some of the mathematical properties of some of these hash algorithms, and also that the size of hash output could be whatever you wished.
You also may believe that pandering to lazy people with weak passwords is of paramount importance. This is a matter of opinion, I suppose. I lost two accounts with a very strong password due to some jackass at eBay apparently storing it plaintext. This is preventable. I've successfully trained most of my family to use quality passphrases. None of them would lose their accounts if this were all properly implemented. Let's save the smart and diligent people and then circle back for the lazy and stupid; that's my motto.
Also, you're against forcing the people running websites to change, because reasons.
I can't give you a comprehensive overview of everything that's out there, but as a personal desktop Qubes (a type 1 hypervisor, i.e. bare metal) is definitely worth a look. This is "at the other end", i.e. it's full OS virtualization, but with a lot of performance, security and usability advantages over its competitors. As of now it's entirely Xen-based but with 3.0 they rewrote a lot of it to abstract away the hypervisor specific stuff and there's been some talk about eventually having LXC containers or making a type II hypervisor that could run on the platform of your choice.
What it does now is run HVMs (which gives you a little window in which another OS runs, as you'll commonly see with Virtualbox or KVM / QEMU) but also AppVMs. The latter are full-featured distros that are specially tailored to run on Qubes. It ships with Debian 8 and Fedora AppVM templates, but as I recall there are community-built versions of other distros. (I personally can't wait to see something like Alpine used as the default template.)
Qubes templates allow you to save disk space (and enhance runtime performance) by having multiple AppVMs be based on a single template. All templates share the same installed applications, but have different home directories,/usr/share and/rw/config directories. Updating or installing new applications is completely separate from using the AppVMs themselves, so there is no mechanism by which data can accidentally leak from one AppVM to another.
Performance is impressive, although you will want to be using an SSD. They use PV drivers and various tricks to make startup times quite fast.... generally under 10 seconds and sometimes under 5.
You don't have one window per VM; instead, each application window appears to be a native window with its own entry in the task bar and alt-tab list. The window borders are color-coded to tell you which window is coming from which VM. It's awesome. And they have a Windows tools that allows the same thing, so you could have a genuine copy of Internet Explorer (not running in Wine, but running in Windows 7) sitting in a task bar right next to your linux desktop applications.
Security is equally impressive, particularly if your machine supports Intel vt-d (it has to support it properly, though; earlier generations of vt-d chipsets didn't always work properly, particularly on non-business class laptops). Joanna is working to move as much out of Dom0 as possible, which enhances security quite a bit; most significantly, Dom0 has no direct network access (if you want to update it, you have to request an update be delivered through one of the VMs that have a network connection; currently, the firewall VM performs this task although I think it should probably be split off into its own separate UpdateVM.) Despite the high walls between the AppVMs, there are hooks that allow them to send files to each other (Dom0 acts as an arbiter, asking you to manually approve of each transfer) and you can copy-paste through a nifty hyper-clipboard (accessed through the keyboard shortcut shift-control c/x/v.)
Finally, you can do 99% of this stuff using the GUI. You need the CLI for installing HVMs and maybe a few other things, but the Qubes VM Manager GUI does almost everything else, and Nautilus (and I think Dolphin?) comes installed with rightclick context menus to send files to other VMs. (You can also write an extension to do this in Thunar very easily.) I wouldn't hesitate to recommend this to an intermediate user--if you've been messing around with Ubuntu for a few years, you could probably handle Qubes just fine.
Actually there are a few other things worth mentioning like DispVMs, Whonix for Tor access, ProxyVMs (awesome for easy VPN configuration) but you can look that stuff up yourself if you're interested.
One last thing, don't install Qubes 3.1 unless you really want a KDE4 interface (as opposed to KDE5 or XFCE4.) Qubes 3.2 is about to be finalized, so either wait for that or install 3.2 RC3.
Incidentally, docker is mostly marketing; alternatives are better.
That may well be; I'm just saying their focus is correct. When I heard a few years back that LXC finally had unprivledged containers I thought "ohh, this is going to be interesting to see what people come up with" and Docker was the most prominent blip on that radar. I don't have enough hands-on experience with the nuts and bolts to say for sure how great the end product is (I'd be a lot more interested in kernel-level containerization if Qubes weren't so delightfully usable), but the goal is certainly worthy.
This is true also of some of the things systemd attempts to do, although certain things (like this cradle to grave process babysitting stuff) very clearly need to be completely separate systems without a ton of shared connective tissue, and without a bunch of major packages depending on it.
However, systemd's dog's breakfast configuration syntax coupled with the enormous number of badly documented, embedded run-time dependencies (not declarative! e.g. killing running daemons that have previously worked for decades "just because") is not.
Yeah, I would like most to see a system where the declarative stage generates the imperative stage and then gets the hell out of the way so that you can manually and arbitrarily edit the imperative stuff. One would assume this would at least in some ways make development easier too, since annoying bugs or incomplete features could be subject to easy work-arounds until time could be found to fix them. Actually, that may well be how parts of OpenRC operate, but I'm not positive. (I've little need to do much init fiddling, so my OpenRC recommendation was mostly going by what I've read and heard about it. Since Upstart is basically dead in the water and a great many people don't want to tolerate SysV indefinitely, OpenRC seems like the most viable long term alternative. Also, it can implement a larger subset of systemd's abilities, which presumably makes it easier to piggyback to some extent on systemd configurations that other projects produce.)
As far as I can tell, the problem is mostly one of personality and ideology. Poettering is a rather unpleasant person who is purposefully choosing to do things in an unnecessarily hostile and control-destroying manner, and Red Hat, while obviously having done tremendous things to help Linux over the years, has been in the business of promoting user-hostile asshatery and lock-in philosophies in recent years, something which hasn't been remarked on nearly as much as it should've (possibly because RHAT earned themselves too many OSS brownie points 10+ years ago and are still making useful contributions today.)
None of that excuses the legions of people around who have said that there was no problem with SysV, or that declarative syntax was worthless (tell that to someone who is trying to build a distro), or treated process control or containerization as inherently unworthy things to be concerned with. I do not say that systemd does these things especially well; I merely say that as concerns, they are intrinsically worthy of consideration.
And if you say that no one needs better containerization options or that stateless systems is a worthless concept or that Debian's old init scripts were the pinnacle of perfection, you clearly do not know what you are talking about. Red Hat does have some fiat sway, but if SysV init were easy to stick with we wouldn't have seen all of the major distros adopt systemd in lockstep. It's not completely worthless. Some of the problems it solves are indeed real. I'm not saying it's worth half a million lines of C code to solve those problems, but the problems are fact there.
But if you actually deny that any problems exist, you're basically just an unthinking hater and no one is paying you any attention except a certain subset of systemd haters who didn't need any more convincing.
This actually isn't so dissimilar to Trump and concerns over immigration or terrorism, but that's an analogy for another day.
If you're dissatisfied with systemd and you don't need any of its fancier capabilities (which as an end user I'm assuming would be Docker stuff), please consider switching to a non-systemd distro as soon as possible and (if you can afford the time or money) contributing to their development. The more support systemd alternatives can garner, the more likely it is that projects to will resist unnecessary systemd dependencies and it might even be that systemd itself will eventually become more modular and moddable.
I'm not a hater. I cringe every time I see +5 comments claiming that systemd didn't fix anything. Declarative syntax is (at least in principle) a massive win, especially for distro builders. And LXC is amazing stuff, and I certainly cannot fault Red Hat for wanting containers to behave perfectly. Unless something like Genode scores a major coup, containers are definitely the future of secure and robust computing.
But the actual details of systemd's course have been hair-raising. It needs to be more UNIX-like and less draconian in its requirements and less toxic in its effects on the FOSS ecosystem and unfortunately (given Red Hat's behavior over the past decade) it appears that pushing alternatives hard is the only way they can conceivably be convinced to change their ways or reform anything moving forward.
I encourage all of the haters here to try and put your money where your mouth is. Install, use, support and help promote a distro like Devuan or even better: go and find one of the multiple OpenRC distros available. OpenRC can't be the all-in-one automagic solution systemd endeavors to be, but it doesn't hide tons of stuff in huge C binaries and it's addressed most of the common frustrations people have with SysV. Arch Linux has an OpenRC variant (the standard install uses systemd), Gentoo was the distro that started OpenRC years ago, and Alpine linux uses it (which isn't an ideal easy desktop distro, but it's amazing for those wanting a secure minimal distro to build on and last time I checked it does run XFCE and Firefox.) There are probably others.
If you're implying that Musk isn't implying anything... I don't know about that. Musk has demonstrated a propensity for hype in the past, most dramatically with the hyperloop, which is certainly not (and feel like I'm telling a five year old that Santa doesn't exist every time I say this) plausibly cost-effective or revolutionary in any of its proposed forms, even using the most generous of assumptions.
Anyone that can ride a pipe dream like that for as long as he had, despite the fact that it's vaccuuming up millions of dollars and raising false hopes in millions of starry-eyed fledging geeks (for the love of god, please don't resort to Wright brothers analogies), certainly seems capable of implying that his competitors sniped his rocket.
That's not to say Musk sucks at rocketry (there's a reason why 'rocket science' has the connotations that it does); just that he's obviously a bit prone to either self-delusion or cynical manipulation of public opinion, and either one could lead him to throw around implications like that.
Actually I should clarify the salt used for the serverside hash doesn't offer much except:
1. Protection vs. precomputed rainbow tables (brute forcing the hash will be slower, which buys you some extra time if a password is moderately weak. Since in my scheme the client-side salt will be known--for ease of use and portability reasons--it would be ideal if the server-side salt was not known in advance.)
2. Protection vs. an improperly salted (or otherwise improperly executed) client hash.
I'm specifically talking about the salt for the server-side hash. You still need the server hash regardless (for the access-denying reasons I described, which obviously won't be doable with client hashing because you can't trust a client run by the attacker to perform the hash properly), but in the presence of a competent client-side salt and hash then #1 is the only benefit provided... but since users can't be expected to provide bulletproof passphrases, it's one that's well worth having. A password like "!unic0rn73" will certainly be crackable with any decent behavioral-aware dictionary attack, but if you remove the possibility of rainbow tables then it may take considerably longer for anyone who doesn't have access to a powerful computing cluster.
Just a detail that was nagging at me; I wanted to clarify the precise roll of both salts: The client pre-hash salt is primarily for minimizing collateral damage from using the password with other sites; the server pre-hash salt is for minimizing the value of a database breach and increasing the amount of time dictionary attacks would take (thus giving them more time to detect the intrusion and giving the users more time to change their weak passwords.)
Pretty sure you've given up at this stage, as you obviously don't have the knowledge or the chops to actually engage me in a debate. I was trained in an extremely technical field and I could and still can debate any point with which I was familiar with anyone, layman or not.
I don't have the time to give you a good picture of humanity's true nature but I will tell you this: appeals to authority usually mean almost nothing, and I've never underestmated the ability for people to engage in and promote incompetent and self-destructive practices, even if it's over a very long period of time whilst in highly visible positions. Nobel Prize winners have shown themselves to be crackpots who believe in pseudoscience. Even within their own field, decades of stagnant busywork have completely rotted the minds of many one-time experts. I don't and can't say for sure that this is what has happened to you, but you are exhibiting the symptoms very strongly.
An inability to justify one's reasons for liking or disliking an idea in a succinct way is one of the defining characteristics of the disease. You should consider an early retirement ASAP, or at the very least a long vacation.
Update: Half a dozen posts later and the best he can come up with is continually criticizing me for not having a CS degree and ten years of experience. A undisguised appeal to his alleged authority and insults... that is literally all he has.
Oh yes, there's that and he objected to me saying "cryptographically secure hashing" and in his very next post he disparaged me for not mentioning, by name, "iterated hashing" because according to him, non-iterated hashing is insecure. I'll let you connect the dots on those two brilliant nuggets of criticism.
I never claimed to be an expert, or to be writing a dissertation or a carefully constructed white paper. The only actual criticism he can offer is for not using his preferred jargon, whilst on the topic of the astounding incompetence over at Yahoo he remains mute. And the jackass is still modded +4 Informative.
I don't have to be a car expert to know that you don't want to put your antifreeze-water mixture into the gas tank.
Provided the summary here is accurate (this was a database leak only and yet accounts that were offline had their login credentials compromised, with no comment about the strength of the passphrase mattering), this is a fuckup of the highest order here and yet you apparently haven't offered a word of technical criticism of it.
Thus, I think it's reasonable to conclude that you are a troll, not a professional, and/or you're for some reason ultra-sensitive about the good folks at Yahoo being criticized.
Slashdot Mirror
When you hash the password on the client, especially (and quite dangerously) if you're using a known and/or easily guessable salt, the hash you transmit to the server simply becomes a markedly weaker authentication token
Demonstrably untrue and indicative of someone who doesn't understand the first thing about hashing algorithms. I'm not saying you can dump it into a single iteration of your command line version of SHA and automagically get something that works. It has to be intelligently constructed, properly utilize all input, and produce output that significantly exceeds the size of the input. If the password field has a maximum, let the hash output be twice that size. Are you still going to argue that "markedly weakens" it? My gut says that if you used a 1:1 algorithm stage in there somewhere that it wouldn't even need to be that big, but I haven't had time to research this in detail. I'm not an expert; I just am not a moron about these things.
I'm sorry if this is rude but I've been more than patient up until now: You people are fucking clueless. You apparently think that just because you've set up a few HTTPS webservers and you use these shitty command line things that you call "hashes" that somehow makes you an expert on information theory. *I* don't claim to be an expert, but I'm also not wrong.
Once the token arrives at the server, per your scheme it would be rehashed, but with what salt? Server side salt reuse here yields the same concerns,
Server should use random salt; sorry if I didn't make that clear. The static salt is for client side only. Random salt for client is either a secret keyfile (undesirable for usability reasons) or it's transmitted from the server, which is makes it just a pointless redundancy with the server-side hash. You *could* have both sides use random salt, I guess. It wouldn't hurt. I was just trying to keep things simpler than that. Random salt that is broadcast is obviously less desirable than random salt that is kept hidden on the server.
I appreciate the effort you're making but I really would like for us to be on the same page before I make any further effort to research and provide you with a more detailed spec of what I'm thinking of here, if indeed that is truly necessary. Several of you guys are misstating what I'm advocating and also asserting blatant falsehoods about hashes worsening security.
You're misusing terminology
Repeatedly conceded. I'm not a professional cryptographer.
your proposal is not backwards compatible (Javascriptless clients)
That's fine--all sites that work properly without javascript are exempt. OK? That still leaves us with 90%+ of the web, which does require JS. Also, I further specified that I'd prefer to see this as a browser function akin to HTTPS.
less effort would be needed from the coder by just doing security properly in the first place.
Unfortunately, we've seen repeated proof that you people cannot be trusted to do it properly on your end. With client-side hashing, strong pressure can be brought to bear on people who aren't using it, companies can prevent their employees from visiting insecure sites, browsers can generate warnings about insecure password fields, etc. They should still use server-side hashing, but if they lie about it then we at least will have the protections that client-side offers.
Furthermore, you've shown in previous threads that you're willing to dismiss any arguments against your proposal.
Citation needed. I've endeavored to address every single objection raise, although so far they've been fairly boneheaded and impolite objections so you shouldn't expect my responses to be candy-coated.
The simplest way to make things secure is by using HTTPS and a store_database(hash($password || $salt)) call in the server code.
You. assholes. cannot. be. trusted. I'm not idly saying this! I've lost two accounts with a very long, unbruteforceable password apparently due to plaintext database storage being used. I've already had one AC poster, ostensibly a slashdot regular working at a major company, talking at length about how they are using plaintext storage and have refused repeated calls to implement salted hashing.
C&P: No payment for fools who don't understand how to use hashes properly.
In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
No payment for fools who don't understand how to use hashes properly. In addition to the below objections, upon further consideration of your description of your experiment I've realized you've almost certainly hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--some of you guys apparently have a very limited understanding of how hashing algorithms can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
oops, please ignore the below reply. I meant it for another AC post.
P.S. As I noted elsewhere, you've probably hopelessly bungled your hash. You shouldn't have tons of collisions like that. A proper hashing algorithm will correctly utilize all of your input and you should produce (and save) output that significantly exceeds the size of the input.
This first occurred to me last night when I was debating another alleged expert cryptographer, who was eventually forced to concede all of my claims--you guys have a very limited understanding of how hashing can be used, their mathematical properties, or how the odds of collisions can be easily adjusted. And none of this requires much CPU overhead if you're already doing HTTPS.
C&P:
1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.
2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic. In particular, the hash should be able to handle on par with the maximum password length and the hash output should exceed the size of the input, possibly greatly exceed it.
3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)
4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that a secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.
You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.
1. I explicitly said in multiple posts, including the original, that I did not care about protecting weak passwords. Protecting weak passwords is something that should be attempted, but requires something a lot more complicated than what I have outlined, which was implicitly and explicitly stated to NOT be a comprehensive. Any reduction in the number of accounts compromised is a win, because the effort to do this is so little.
2. I'm not sure if you're implying that your salted hash reduced entropy, but if that's the case then either your hash algorithm sucks or you did something moronic.
3. I explicitly said that a random salted hash should be used for server-side hash (I might have had to clarify that the server salt was random in another post)
4. Using a random hash for client-side is obviously unworkable (if kept secret from the server) or a much less secure (redundant but crappier) version of the server-side hash with random salt. All you've "proved" here is that secret key (i.e. using random salt for the client side hash) is better than a simple static salt hash. Which I explicitly said in the original post--keyfiles are better, but they're obviously unworkable for most places because it imposes an extra burden on the users.
You've failed in multiple ways here. Work on your reading comprehension skills and try again, if you wish.
And in fact, I'd argue that with any JS-based solution an average user couldn't either
But security bulletins could be posted. Companies could prevent people from visiting sites that refuse to use client-side hashing. Browsers could warn you with dire-sounding popups. Pressure could be brought to bear. As I've already described, it doesn't replace server-side hashing but if they are dumbasses about it then it at least mitigates some of the damage done by a lack of server-side hashing.
It's only "not easy" in the sense that any change requires work. It's not something that requires much more CPU work than what HTTPS already requires. It's not something that would take more than a couple weeks to set up, test and deploy. Do you disagree?
Hitler meant it. Trump doesn't. Trump is an amoral twat more concerned with popularity. Saying that he'll deport 11 million people or whatever it was, doesn't make it so. The next jerkoff to come along might mean it, but I don't think a Trump presidency makes that more likely (actually, probably very slightly less likely.)
That said, I'm not pro-Trump for reasons already outlined.
This is one decent upside from my perspective: anything that accelerates GNOME's downfall or at least decreases their market share is a good thing. Their devs badly need to learn some humility and perspective. They not only appear to believe they can be the next Apple, but they believe that the key to doing so is to treat its users like dirt, not realizing that this was an unnecessary side effect and not a causative agent in Apple's success.
This might have carried some weight in the Bush years, but the fact is Obama and the rest of the democrats did very little to undo the most egregious damage.
Trump is an outsider. His damage from recklessness (if indeed he maintains the same persona--more on this momentarily) is less likely to lead down the road to dictatorship than Hillary. Reports of his Hitlerishness have been greatly, greatly exaggerated and do much to alienate many people who might otherwise have been talked out of a Trump vote. Calling Trump the next Hitler has never swayed the opinion of a single person who was on the fence. If you don't understand this, then you don't understand anything.
That said, he's far too stupid and lazy to actually inflict any real damage of that sort. He's going to end up as a puppet of the Republicans, just as bad as Bush ever was (so, there's *that* kind of damage), except he'll occasionally do something especially wacky (but entirely inconsequential) just 'prove' that he's an outsider. So, this likely outcome rather cancels my above analysis. He's not worth voting for precisely because he is not likely to burn anything down, and the Republican establishment is a great deal more odious than the Democratic establishment.
But I'm not a fan of either, so... please vote Johnson or Stein. It doesn't matter which. It doesn't matter; it's not about them winning, it's about laying the foundation for the breakup, or at least the shakeup, of the two-party system. Don't stay at home, and for fuck's sake don't vote for the lesser of two evils. The best hope we have of burning anything to the ground is by not voting for either party, period.
The fact that you think this about ego really says it all. You think that I think that this is some brilliant, complex, end-all and be-all solution. I explicitly said it wasn't. It isn't a credit to my intellect, not in the slightest. It's a 'credit' to yahoo's stupidity that they didn't do this. And it's a credit to yours that you've posted like what, perhaps ten pointlessly hand-waving posts of zero content, arguing that my ideas are broken because you have more than ten years of experience, that's why!
I can't even begin to describe how much joy it brings me to hear you spout such idiocy. Please, do it again.
We didn't have a unprivileged LXC, vt-x or vt-d in 2004. Compartmentalization is the foundation of good computing practices; hell, it's what UNIX was famous for. It's a way of bootstrapping microkernel-like structures into a monolithic system, which might be ass-backwards but it can work pretty damn well.
Also, as I've said before in response to this very subject, the fact that something has been done before has nothing to do with whether or not it'll become popular now. Lisp was doing things in the 1970s that we didn't really see again in other mainstream programming languages until the 2000s. The Amiga was a bit ahead of its time as well. Sometimes these things do take time.
You should be careful with this. I don't disagree at all with the broader criticism of Red Hat's politicking; in fact in many ways I think the criticism has been far too limited. For example, their involvement in GNOME is inexcusable given not just the attitudes of the devs but also the explicit stated goals of the project.
But the longer you deny that there is any point whatsoever to systemd, the more damage you do to your cause, because it *does* do some stuff that it tricky to do in SysV. Want to change peoples' minds? Show them how to do something similar in OpenRC, or explain some other workaround. Emphasizing only the bad and pretending that the good doesn't exist usually does not end well, even if the good is overwhelmingly outweighed by the bad.
For example: containers are not fucking niche usage cases. Containers are the future of secure, robust, high performance computing. In the future, they will be widely used regardless of whether or not the user realizes that they are being used. Calling them niches that most users don't care about makes me think that he is a clueless, dogmatic fool. It makes me less likely to pay much attention to anything else he says.
You've no idea. This isn't about ego at all; I simply enjoy watching people make asses of themselves. Feel free to call me a sadist, if that makes you feel any better.
And it turns out, I can do your arguing for you! I found another crypto "expert" that I'm IMing at the moment and just like you he threw a hissy fit at first, but after 45 minutes he was forced to concede every single one of my core claims, while still claiming that it would never work in practice because they would never do it, which isn't an argument I find very compelling.
But your problem, I believe, is a psychological aversion to offline attacks. You like shit to stay online where things can be drastically limited and even CAPTCHAs can be used. Fair enough: ok then, if you're paranoid then you're allowed to change your password after a break, even if it was a very strong password. Who said you couldn't? Security is about roadblocks, not absolutes. And you can put a huge roadblock up by applying a good hash to a good password, a roadblock that shouldn't be breakable by any world power today in a reasonable time frame. But, then, I might be slightly more tenacious than most; my FDE password is over 100 characters.
Speaking of good hashes, you also may have an unhealthy mental picture of the purpose and limitations of hashing algorithms. In reality, collisions don't have to be a problem if you don't let them be. At first, the guy I'm talking to wanted to argue like crazy that collisions were always inevitable until I started pointing out some of the mathematical properties of some of these hash algorithms, and also that the size of hash output could be whatever you wished.
You also may believe that pandering to lazy people with weak passwords is of paramount importance. This is a matter of opinion, I suppose. I lost two accounts with a very strong password due to some jackass at eBay apparently storing it plaintext. This is preventable. I've successfully trained most of my family to use quality passphrases. None of them would lose their accounts if this were all properly implemented. Let's save the smart and diligent people and then circle back for the lazy and stupid; that's my motto.
Also, you're against forcing the people running websites to change, because reasons.
Am I getting warm?
You aren't terribly unique, either.
I can't give you a comprehensive overview of everything that's out there, but as a personal desktop Qubes (a type 1 hypervisor, i.e. bare metal) is definitely worth a look. This is "at the other end", i.e. it's full OS virtualization, but with a lot of performance, security and usability advantages over its competitors. As of now it's entirely Xen-based but with 3.0 they rewrote a lot of it to abstract away the hypervisor specific stuff and there's been some talk about eventually having LXC containers or making a type II hypervisor that could run on the platform of your choice.
/usr/share and /rw/config directories. Updating or installing new applications is completely separate from using the AppVMs themselves, so there is no mechanism by which data can accidentally leak from one AppVM to another.
What it does now is run HVMs (which gives you a little window in which another OS runs, as you'll commonly see with Virtualbox or KVM / QEMU) but also AppVMs. The latter are full-featured distros that are specially tailored to run on Qubes. It ships with Debian 8 and Fedora AppVM templates, but as I recall there are community-built versions of other distros. (I personally can't wait to see something like Alpine used as the default template.)
Qubes templates allow you to save disk space (and enhance runtime performance) by having multiple AppVMs be based on a single template. All templates share the same installed applications, but have different home directories,
Performance is impressive, although you will want to be using an SSD. They use PV drivers and various tricks to make startup times quite fast.... generally under 10 seconds and sometimes under 5.
You don't have one window per VM; instead, each application window appears to be a native window with its own entry in the task bar and alt-tab list. The window borders are color-coded to tell you which window is coming from which VM. It's awesome. And they have a Windows tools that allows the same thing, so you could have a genuine copy of Internet Explorer (not running in Wine, but running in Windows 7) sitting in a task bar right next to your linux desktop applications.
Security is equally impressive, particularly if your machine supports Intel vt-d (it has to support it properly, though; earlier generations of vt-d chipsets didn't always work properly, particularly on non-business class laptops). Joanna is working to move as much out of Dom0 as possible, which enhances security quite a bit; most significantly, Dom0 has no direct network access (if you want to update it, you have to request an update be delivered through one of the VMs that have a network connection; currently, the firewall VM performs this task although I think it should probably be split off into its own separate UpdateVM.) Despite the high walls between the AppVMs, there are hooks that allow them to send files to each other (Dom0 acts as an arbiter, asking you to manually approve of each transfer) and you can copy-paste through a nifty hyper-clipboard (accessed through the keyboard shortcut shift-control c/x/v.)
Finally, you can do 99% of this stuff using the GUI. You need the CLI for installing HVMs and maybe a few other things, but the Qubes VM Manager GUI does almost everything else, and Nautilus (and I think Dolphin?) comes installed with rightclick context menus to send files to other VMs. (You can also write an extension to do this in Thunar very easily.) I wouldn't hesitate to recommend this to an intermediate user--if you've been messing around with Ubuntu for a few years, you could probably handle Qubes just fine.
Actually there are a few other things worth mentioning like DispVMs, Whonix for Tor access, ProxyVMs (awesome for easy VPN configuration) but you can look that stuff up yourself if you're interested.
One last thing, don't install Qubes 3.1 unless you really want a KDE4 interface (as opposed to KDE5 or XFCE4.) Qubes 3.2 is about to be finalized, so either wait for that or install 3.2 RC3.
Incidentally, docker is mostly marketing; alternatives are better.
That may well be; I'm just saying their focus is correct. When I heard a few years back that LXC finally had unprivledged containers I thought "ohh, this is going to be interesting to see what people come up with" and Docker was the most prominent blip on that radar. I don't have enough hands-on experience with the nuts and bolts to say for sure how great the end product is (I'd be a lot more interested in kernel-level containerization if Qubes weren't so delightfully usable), but the goal is certainly worthy.
This is true also of some of the things systemd attempts to do, although certain things (like this cradle to grave process babysitting stuff) very clearly need to be completely separate systems without a ton of shared connective tissue, and without a bunch of major packages depending on it.
However, systemd's dog's breakfast configuration syntax coupled with the enormous number of badly documented, embedded run-time dependencies (not declarative! e.g. killing running daemons that have previously worked for decades "just because") is not.
Yeah, I would like most to see a system where the declarative stage generates the imperative stage and then gets the hell out of the way so that you can manually and arbitrarily edit the imperative stuff. One would assume this would at least in some ways make development easier too, since annoying bugs or incomplete features could be subject to easy work-arounds until time could be found to fix them. Actually, that may well be how parts of OpenRC operate, but I'm not positive. (I've little need to do much init fiddling, so my OpenRC recommendation was mostly going by what I've read and heard about it. Since Upstart is basically dead in the water and a great many people don't want to tolerate SysV indefinitely, OpenRC seems like the most viable long term alternative. Also, it can implement a larger subset of systemd's abilities, which presumably makes it easier to piggyback to some extent on systemd configurations that other projects produce.)
As far as I can tell, the problem is mostly one of personality and ideology. Poettering is a rather unpleasant person who is purposefully choosing to do things in an unnecessarily hostile and control-destroying manner, and Red Hat, while obviously having done tremendous things to help Linux over the years, has been in the business of promoting user-hostile asshatery and lock-in philosophies in recent years, something which hasn't been remarked on nearly as much as it should've (possibly because RHAT earned themselves too many OSS brownie points 10+ years ago and are still making useful contributions today.)
None of that excuses the legions of people around who have said that there was no problem with SysV, or that declarative syntax was worthless (tell that to someone who is trying to build a distro), or treated process control or containerization as inherently unworthy things to be concerned with. I do not say that systemd does these things especially well; I merely say that as concerns, they are intrinsically worthy of consideration.
And if you say that no one needs better containerization options or that stateless systems is a worthless concept or that Debian's old init scripts were the pinnacle of perfection, you clearly do not know what you are talking about. Red Hat does have some fiat sway, but if SysV init were easy to stick with we wouldn't have seen all of the major distros adopt systemd in lockstep. It's not completely worthless. Some of the problems it solves are indeed real. I'm not saying it's worth half a million lines of C code to solve those problems, but the problems are fact there.
But if you actually deny that any problems exist, you're basically just an unthinking hater and no one is paying you any attention except a certain subset of systemd haters who didn't need any more convincing.
This actually isn't so dissimilar to Trump and concerns over immigration or terrorism, but that's an analogy for another day.
If you're dissatisfied with systemd and you don't need any of its fancier capabilities (which as an end user I'm assuming would be Docker stuff), please consider switching to a non-systemd distro as soon as possible and (if you can afford the time or money) contributing to their development. The more support systemd alternatives can garner, the more likely it is that projects to will resist unnecessary systemd dependencies and it might even be that systemd itself will eventually become more modular and moddable.
I'm not a hater. I cringe every time I see +5 comments claiming that systemd didn't fix anything. Declarative syntax is (at least in principle) a massive win, especially for distro builders. And LXC is amazing stuff, and I certainly cannot fault Red Hat for wanting containers to behave perfectly. Unless something like Genode scores a major coup, containers are definitely the future of secure and robust computing.
But the actual details of systemd's course have been hair-raising. It needs to be more UNIX-like and less draconian in its requirements and less toxic in its effects on the FOSS ecosystem and unfortunately (given Red Hat's behavior over the past decade) it appears that pushing alternatives hard is the only way they can conceivably be convinced to change their ways or reform anything moving forward.
I encourage all of the haters here to try and put your money where your mouth is. Install, use, support and help promote a distro like Devuan or even better: go and find one of the multiple OpenRC distros available. OpenRC can't be the all-in-one automagic solution systemd endeavors to be, but it doesn't hide tons of stuff in huge C binaries and it's addressed most of the common frustrations people have with SysV. Arch Linux has an OpenRC variant (the standard install uses systemd), Gentoo was the distro that started OpenRC years ago, and Alpine linux uses it (which isn't an ideal easy desktop distro, but it's amazing for those wanting a secure minimal distro to build on and last time I checked it does run XFCE and Firefox.) There are probably others.
I doubt it.
If you're implying that Musk isn't implying anything... I don't know about that. Musk has demonstrated a propensity for hype in the past, most dramatically with the hyperloop, which is certainly not (and feel like I'm telling a five year old that Santa doesn't exist every time I say this) plausibly cost-effective or revolutionary in any of its proposed forms, even using the most generous of assumptions.
Anyone that can ride a pipe dream like that for as long as he had, despite the fact that it's vaccuuming up millions of dollars and raising false hopes in millions of starry-eyed fledging geeks (for the love of god, please don't resort to Wright brothers analogies), certainly seems capable of implying that his competitors sniped his rocket.
That's not to say Musk sucks at rocketry (there's a reason why 'rocket science' has the connotations that it does); just that he's obviously a bit prone to either self-delusion or cynical manipulation of public opinion, and either one could lead him to throw around implications like that.
Actually I should clarify the salt used for the serverside hash doesn't offer much except:
1. Protection vs. precomputed rainbow tables (brute forcing the hash will be slower, which buys you some extra time if a password is moderately weak. Since in my scheme the client-side salt will be known--for ease of use and portability reasons--it would be ideal if the server-side salt was not known in advance.)
2. Protection vs. an improperly salted (or otherwise improperly executed) client hash.
I'm specifically talking about the salt for the server-side hash. You still need the server hash regardless (for the access-denying reasons I described, which obviously won't be doable with client hashing because you can't trust a client run by the attacker to perform the hash properly), but in the presence of a competent client-side salt and hash then #1 is the only benefit provided... but since users can't be expected to provide bulletproof passphrases, it's one that's well worth having. A password like "!unic0rn73" will certainly be crackable with any decent behavioral-aware dictionary attack, but if you remove the possibility of rainbow tables then it may take considerably longer for anyone who doesn't have access to a powerful computing cluster.
Just a detail that was nagging at me; I wanted to clarify the precise roll of both salts: The client pre-hash salt is primarily for minimizing collateral damage from using the password with other sites; the server pre-hash salt is for minimizing the value of a database breach and increasing the amount of time dictionary attacks would take (thus giving them more time to detect the intrusion and giving the users more time to change their weak passwords.)
Pretty sure you've given up at this stage, as you obviously don't have the knowledge or the chops to actually engage me in a debate. I was trained in an extremely technical field and I could and still can debate any point with which I was familiar with anyone, layman or not.
I don't have the time to give you a good picture of humanity's true nature but I will tell you this: appeals to authority usually mean almost nothing, and I've never underestmated the ability for people to engage in and promote incompetent and self-destructive practices, even if it's over a very long period of time whilst in highly visible positions. Nobel Prize winners have shown themselves to be crackpots who believe in pseudoscience. Even within their own field, decades of stagnant busywork have completely rotted the minds of many one-time experts. I don't and can't say for sure that this is what has happened to you, but you are exhibiting the symptoms very strongly.
An inability to justify one's reasons for liking or disliking an idea in a succinct way is one of the defining characteristics of the disease. You should consider an early retirement ASAP, or at the very least a long vacation.
Update: Half a dozen posts later and the best he can come up with is continually criticizing me for not having a CS degree and ten years of experience. A undisguised appeal to his alleged authority and insults... that is literally all he has.
Oh yes, there's that and he objected to me saying "cryptographically secure hashing" and in his very next post he disparaged me for not mentioning, by name, "iterated hashing" because according to him, non-iterated hashing is insecure. I'll let you connect the dots on those two brilliant nuggets of criticism.
I never claimed to be an expert, or to be writing a dissertation or a carefully constructed white paper. The only actual criticism he can offer is for not using his preferred jargon, whilst on the topic of the astounding incompetence over at Yahoo he remains mute. And the jackass is still modded +4 Informative.
I don't have to be a car expert to know that you don't want to put your antifreeze-water mixture into the gas tank.
Provided the summary here is accurate (this was a database leak only and yet accounts that were offline had their login credentials compromised, with no comment about the strength of the passphrase mattering), this is a fuckup of the highest order here and yet you apparently haven't offered a word of technical criticism of it.
Thus, I think it's reasonable to conclude that you are a troll, not a professional, and/or you're for some reason ultra-sensitive about the good folks at Yahoo being criticized.