And if you had even 10 passwords that hashed the same, you'd still be able to tell the real password from the gobbledygook of the others (unless they were randomly chosen).
And anyway, other systems that used the same hashing technique would still be vulnerable to each of the lot of colliding passwords.
I don't think that brute forcing to identify passwords is what's meant by "recoverable" here. Though, I suppose I'm with you in the idea that if it's easy enough it's virtually the same.
I'm not getting what (other) significance you're assigning to the idea of passwords being much lower entropy than their hashes. Is there something about the relative entropies that matters, or are you just again pointing to the ease of brute forcing something like passwords (which are going to be, in practice, only a small fraction of the hash entropy), which exists regardless of the potential hash entropy?
It's a kind of psychoacoustic compression, not just physioacoustic compression. It does not have the same "playback" in the range of human auditory sensation. It aims to have the same "playback" with human auditory perception. There's a difference.
... without significant losses in the (consciously) perceived quality of the sound
Physiology is a large of it, but it's not all of it. If you compare MP3 output versus original signal with each limited to the range of human hearing you will still see differences. The idea, man, is that those differences fall between the cracks in your mind... whoa. (Or maybe also brain, if there's a distinction to be made about it.)
If the same transducer reproduces ultrasonics along with audible content, any nonlinearity will shift some of the ultrasonic content down into the audible range as an uncontrolled spray of intermodulation distortion products covering the entire audible spectrum.
My barber was saying this exact thing to me the other day. So I says to him, "Frank, come on, can't you just correct for nonlinearities?" and he laughed at me and gave me a look like he couldn't believe me. I've decided to change barbers.
Maybe they measured power consumption with IE running and then not, or then with a different browser. The power difference is really the result of the browser, isn't it? If it's the only thing changing?
Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.
Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.
I used to see Internet Explorer as the devil, so full of holes it would result in your Windows box needing a reinstall every couple months.
I was aggressively advocating switching from IE around the apex of this curve, and overjoyed as it plummeted.
Are my prior impression about IE being buggy and dangerous still valid? Has IE cleaned up any? I get the impression it has.
And I was pushing folks to use Firefox as the alternative. How does Firefox compare to IE now? I get the impression IE is still a bad choice for a number of reasons, but also that Firefox is itself playing a game of clean-up after bloat issues.
Basically, at this point I'll push folks to use any browser that's not dominant. Get it? Fragmented influence in browser protocols means we get standards and standards compliance instead of the nightmare incompatibilities from intentional protocol "extending" and corrupting that MS and NS were pushing in their bids for complete control.
Makes me want to go back to the 2003 Slashdot posts to identify the IE advocates so I can publicly shame them now.
Yeah, that's the problem with a truly free market. Consumers are stupid and inattentive, corporations are clever and evasive.
If every consumer were Ralph Nader I'd be a free market zealot. As that's not the case we have to find a different way to assure corporations behave themselves.
I think maybe you have a naive or incomplete view.
You don't think big pharma do tons of their own drug discovery? They just get leads from academia?
If I ran a pharmaceutical company I wouldn't let you anywhere near executive management or the board. You don't get it. The idea of me-too drug development would totally blindside you.
An "office" computer and thin client is a different use scenario from a server. Yeah, he did make a bad comparison, but don't let that steer you off into the weeds. "Real work" and "PC replacement" as he termed it is meant to describe "office" activity. I use my desktop to do email and office document handling and to connect to servers. I don't run servers on my desktop (at work).
The point he's making is that the work he does is handled fine by smartphone-level computing power. You just need good Human Interface Devices and display.
I don't think it's hard to find examples of Theo being contemptuous outside of handling an indolent noob.
Since both emacs and gcc contain code inside them which permit them to compile and run on commercial operating systems which are non-free, you are a slimy hypocrite.
Stallman isn't a noob. He has a different perspective from Theo, obviously. Any reason not to be a gentleman about it?
And, contempt for indolent noobs, as it turns out, is still counterproductive. Because contempt by itself is counterproductive.
I can appreciate trying to raise the floor with a dress code or basic code of conduct, but a culture of contempt is actually counterproductive. It results in a "blame culture", which is inherently less secure. And both these negative qualities reduce the viability of the community and stunt its growth and progress. There are other ways to raise the floor.
pfSense is a distribution whose whole purpose is simplifying the administration of pf? With another major goal of reliability? What would you expect, then?
The editing around here normally stinks, but either the editor or the submitter (more likely) did a great job of averting the possible ambiguity here by judicious application of a hyphen. "13 hour-long episodes" is perfect. As much as I'm inclined to roll my eyes at the editing and snark it in comments, I should point out when it works. Well done.
People like to hear that DNSBLs are a problem. And then they like to repeat the accusations. Not sure how folks have gotten attached to the idea, but I'm certain it's not from detailed investigation.
For one thing, don't conflate the mechanism with the implementations. Anyone can publish a DNSBL. You could. And you could make your list all false positives. It would be a bad idea for people to subscribe to your list. Caveat emptor, right?
And that's why you get false positives. You've chosen badly. And you're not using the lists for scoring — sounds like you're using them as final arbiters.
The "trick" to getting DNSBLs to work is to choose wisely. You have to do some research into how the lists are made, and since it's you who will be blocking emails based on the information provided by the lists, it's your responsibility to understand the nature of that information. What are the listing/delisting policies? If you don't know, you're not being a smart consumer. "... everytime some angry recipient with a vengeace decided to file a spam-report..." Hopefully you know better than to think that every DNSBL is made this way.
And the "smart" spam filters, so you know, are resource intensive. Instead, it's possible to eliminate lots of spam using extremely low resource checks. Validating the SMTP "HELO" (requiring they give FQDN, non-bare address literals, not your domain or IP, and a couple other checks as per RFC) will nix half of spam off the bat. And you can eliminate another third of spam (two-thirds the spam passing HELO checks) by using (well-chosen) DNSBLs. DNS lookups are cheap (and you can download zone files of you're worried about outages). That's 83% of spam cheaply nixed, all before you even get to "MAIL FROM:". If your "smart" checks are building Markov chains and feeding a naive Bayes classifier, that's gonna take time and effort in processing power, in disk resource, in procedures and staff attention/knowledge for maintenance.
DNSBLs are clearly a way to fight spam. But you have to know what they are and how to use them.
Shopping for DNSBLs takes effort, it's true. If you want to do a good job. Once upon a time, Al Iverson's http://www.dnsbl.info/ was up-to-date and gave wonderful statistics on success rates of the various lists (using his (rather knowledgeable) measures). Doing the research now without such a resource is much more challenging.
I use Spamhaus's XBL and SpamCop's SCBL. That's it. Combined, those give me the aforementioned inexpensive 33% spam reduction. (If I used them before the HELO checks the reduction would probably be near 75%, my guess.) I vetted the lists for efficacy (true positives v. false positives), policy (how they're made, listing and delisting), and longevity/reputability. I've been using these guys for 5 years without a hiccup.
It's a good question. You would do well to read up on how DNSBLs and DNS work. If a DNSBL's authoritative server goes down there's no risk of false positives. You don't get a positive response for random IPs when the list is not answering. And if you look up the IP of someone who's actually sending spam and you don't get a positive result, that's okay too. The list shouldn't be your only check for whether something is spam. And if you look up an IP and the server doesn't give any response, that's okay too. Your mail system shouldn't freak out and mark the email as spam or otherwise fail to handle the email.
The different lists published by Spamhaus distinguish whether the IPs are directly responsible or are organizationally related. There is no abuse of power here — customers subscribe to the lists that they want, and use those lists to block as they see fit. Spamhaus isn't forcing anyone to use the lists, nor is it misrepresenting what's in the lists.
I think the idea is that acting as you imagine you would behave correlates more highly with how you actually would behave than randomness does. Take the data as a correlation, be cognizant of the possible degrees of accuracy, and extrapolate from there. You maybe get broad strokes showing you the directions things could go in an actual situation, but that's not nothin'.
Actually, moving sshd to a different port is for added security.
It'll be some time before automated scans and worms try to find SSH on something other than port 22 in any substantial frequency. So moving the port gets you a reduction in attack frequency. That's of value. It's additional security.
Requiring a remote system to send SYN packets to 16111 28123 and 22222 before opening port 22 to them is just another way to reduce frequency (albeit using a much higher hurdle). The difference is degree, not kind, so it's not that one of these actions is actual security and the other isn't.
The point behind having 4 different solutions was to be flexible in my thinking, ready for whatever a scenario might call for. The question, being a test question without a genuine context, leaves open the range of possibilities, using only a hint (in place) to constrain the solution. There are situations that could use the two algorithms you find unsuitable (unsuitable presumably for the situations you commonly experience and thus judge things by).
Slashdot Mirror
Ah, that makes sense.
And if you had even 10 passwords that hashed the same, you'd still be able to tell the real password from the gobbledygook of the others (unless they were randomly chosen).
And anyway, other systems that used the same hashing technique would still be vulnerable to each of the lot of colliding passwords.
I don't think that brute forcing to identify passwords is what's meant by "recoverable" here. Though, I suppose I'm with you in the idea that if it's easy enough it's virtually the same.
I'm not getting what (other) significance you're assigning to the idea of passwords being much lower entropy than their hashes. Is there something about the relative entropies that matters, or are you just again pointing to the ease of brute forcing something like passwords (which are going to be, in practice, only a small fraction of the hash entropy), which exists regardless of the potential hash entropy?
Not a lot of 200 ton bees out there...
http://www.mnn.com/earth-matters/wilderness-resources/photos/7-amazing-examples-of-biomimicry/sharkskin-swimsuit
I thought he was a mech pilot.
It's a kind of psychoacoustic compression, not just physioacoustic compression. It does not have the same "playback" in the range of human auditory sensation. It aims to have the same "playback" with human auditory perception. There's a difference.
Physiology is a large of it, but it's not all of it. If you compare MP3 output versus original signal with each limited to the range of human hearing you will still see differences. The idea, man, is that those differences fall between the cracks in your mind... whoa. (Or maybe also brain, if there's a distinction to be made about it.)
My barber was saying this exact thing to me the other day. So I says to him, "Frank, come on, can't you just correct for nonlinearities?" and he laughed at me and gave me a look like he couldn't believe me. I've decided to change barbers.
Maybe they measured power consumption with IE running and then not, or then with a different browser. The power difference is really the result of the browser, isn't it? If it's the only thing changing?
Even then not a reasonable comparison. The ability for the scanned proprietary softwares' teams to decide on inclusion feels to me like it would really influence the stats.
Would you expect there to exist any correlation between how shoddy software is and how likely the authors are to share information about how shoddy their software is? I would expect some correlation.
I used to see Internet Explorer as the devil, so full of holes it would result in your Windows box needing a reinstall every couple months.
I was aggressively advocating switching from IE around the apex of this curve, and overjoyed as it plummeted.
Are my prior impression about IE being buggy and dangerous still valid? Has IE cleaned up any? I get the impression it has.
And I was pushing folks to use Firefox as the alternative. How does Firefox compare to IE now? I get the impression IE is still a bad choice for a number of reasons, but also that Firefox is itself playing a game of clean-up after bloat issues.
Basically, at this point I'll push folks to use any browser that's not dominant. Get it? Fragmented influence in browser protocols means we get standards and standards compliance instead of the nightmare incompatibilities from intentional protocol "extending" and corrupting that MS and NS were pushing in their bids for complete control.
Makes me want to go back to the 2003 Slashdot posts to identify the IE advocates so I can publicly shame them now.
Yeah, that's the problem with a truly free market. Consumers are stupid and inattentive, corporations are clever and evasive.
If every consumer were Ralph Nader I'd be a free market zealot. As that's not the case we have to find a different way to assure corporations behave themselves.
I think maybe you have a naive or incomplete view.
You don't think big pharma do tons of their own drug discovery? They just get leads from academia?
If I ran a pharmaceutical company I wouldn't let you anywhere near executive management or the board. You don't get it. The idea of me-too drug development would totally blindside you.
An "office" computer and thin client is a different use scenario from a server. Yeah, he did make a bad comparison, but don't let that steer you off into the weeds. "Real work" and "PC replacement" as he termed it is meant to describe "office" activity. I use my desktop to do email and office document handling and to connect to servers. I don't run servers on my desktop (at work).
The point he's making is that the work he does is handled fine by smartphone-level computing power. You just need good Human Interface Devices and display.
http://www.pcmag.com/slideshow_viewer/0,3253,l=208344&a=208341&po=8,00.asp
I don't think it's hard to find examples of Theo being contemptuous outside of handling an indolent noob.
Stallman isn't a noob. He has a different perspective from Theo, obviously. Any reason not to be a gentleman about it?
And, contempt for indolent noobs, as it turns out, is still counterproductive. Because contempt by itself is counterproductive.
I can appreciate trying to raise the floor with a dress code or basic code of conduct, but a culture of contempt is actually counterproductive. It results in a "blame culture", which is inherently less secure. And both these negative qualities reduce the viability of the community and stunt its growth and progress. There are other ways to raise the floor.
pfSense is a distribution whose whole purpose is simplifying the administration of pf? With another major goal of reliability? What would you expect, then?
I should point out that SMTP transport is by nature complicated.
And that's only item #4 out of their goals. Everything else is pretty much covered.
And what the hell are people doing using Sendmail? Use Postfix or qmail.
The editing around here normally stinks, but either the editor or the submitter (more likely) did a great job of averting the possible ambiguity here by judicious application of a hyphen. "13 hour-long episodes" is perfect. As much as I'm inclined to roll my eyes at the editing and snark it in comments, I should point out when it works. Well done.
People like to hear that DNSBLs are a problem. And then they like to repeat the accusations. Not sure how folks have gotten attached to the idea, but I'm certain it's not from detailed investigation.
For one thing, don't conflate the mechanism with the implementations. Anyone can publish a DNSBL. You could. And you could make your list all false positives. It would be a bad idea for people to subscribe to your list. Caveat emptor, right?
And that's why you get false positives. You've chosen badly. And you're not using the lists for scoring — sounds like you're using them as final arbiters.
The "trick" to getting DNSBLs to work is to choose wisely. You have to do some research into how the lists are made, and since it's you who will be blocking emails based on the information provided by the lists, it's your responsibility to understand the nature of that information. What are the listing/delisting policies? If you don't know, you're not being a smart consumer. "... everytime some angry recipient with a vengeace decided to file a spam-report ..." Hopefully you know better than to think that every DNSBL is made this way.
And the "smart" spam filters, so you know, are resource intensive. Instead, it's possible to eliminate lots of spam using extremely low resource checks. Validating the SMTP "HELO" (requiring they give FQDN, non-bare address literals, not your domain or IP, and a couple other checks as per RFC) will nix half of spam off the bat. And you can eliminate another third of spam (two-thirds the spam passing HELO checks) by using (well-chosen) DNSBLs. DNS lookups are cheap (and you can download zone files of you're worried about outages). That's 83% of spam cheaply nixed, all before you even get to "MAIL FROM:". If your "smart" checks are building Markov chains and feeding a naive Bayes classifier, that's gonna take time and effort in processing power, in disk resource, in procedures and staff attention/knowledge for maintenance.
DNSBLs are clearly a way to fight spam. But you have to know what they are and how to use them.
Shopping for DNSBLs takes effort, it's true. If you want to do a good job. Once upon a time, Al Iverson's http://www.dnsbl.info/ was up-to-date and gave wonderful statistics on success rates of the various lists (using his (rather knowledgeable) measures). Doing the research now without such a resource is much more challenging.
I use Spamhaus's XBL and SpamCop's SCBL. That's it. Combined, those give me the aforementioned inexpensive 33% spam reduction. (If I used them before the HELO checks the reduction would probably be near 75%, my guess.) I vetted the lists for efficacy (true positives v. false positives), policy (how they're made, listing and delisting), and longevity/reputability. I've been using these guys for 5 years without a hiccup.
Can you forward me one of those spam-binned emails (with full headers)?
It's a good question. You would do well to read up on how DNSBLs and DNS work. If a DNSBL's authoritative server goes down there's no risk of false positives. You don't get a positive response for random IPs when the list is not answering. And if you look up the IP of someone who's actually sending spam and you don't get a positive result, that's okay too. The list shouldn't be your only check for whether something is spam. And if you look up an IP and the server doesn't give any response, that's okay too. Your mail system shouldn't freak out and mark the email as spam or otherwise fail to handle the email.
You feel dirty for using the Spamhaus blacklists? Which ones do you use? Do you know how they're generated?
I don't use the SBL, though I'm philosophically not that far from approving of it.
I don't use the PBL, I just disagree with the idea behind it.
I don't use ZEN, obviously, being an aggregate including lists I don't agree with.
I do use XBL. To me it just makes sense. And I don't have one whit of regret about it.
The different lists published by Spamhaus distinguish whether the IPs are directly responsible or are organizationally related. There is no abuse of power here — customers subscribe to the lists that they want, and use those lists to block as they see fit. Spamhaus isn't forcing anyone to use the lists, nor is it misrepresenting what's in the lists.
I think the idea is that acting as you imagine you would behave correlates more highly with how you actually would behave than randomness does. Take the data as a correlation, be cognizant of the possible degrees of accuracy, and extrapolate from there. You maybe get broad strokes showing you the directions things could go in an actual situation, but that's not nothin'.
Actually, moving sshd to a different port is for added security.
It'll be some time before automated scans and worms try to find SSH on something other than port 22 in any substantial frequency. So moving the port gets you a reduction in attack frequency. That's of value. It's additional security.
Requiring a remote system to send SYN packets to 16111 28123 and 22222 before opening port 22 to them is just another way to reduce frequency (albeit using a much higher hurdle). The difference is degree, not kind, so it's not that one of these actions is actual security and the other isn't.
The point behind having 4 different solutions was to be flexible in my thinking, ready for whatever a scenario might call for. The question, being a test question without a genuine context, leaves open the range of possibilities, using only a hint (in place) to constrain the solution. There are situations that could use the two algorithms you find unsuitable (unsuitable presumably for the situations you commonly experience and thus judge things by).