The worst part about donating isn't the lingering banners (adblock can be set to take care of them easily). It's the WMF spam. I donated once, a mistake I'll never make again. Once I donated, I was automatically subscribed to a "donators" mailing list, which they used to bombard me with requests to ask my friends to donate, subscribe to a recurring donation model, etc.. Instead, I told my friends that if they donate to Wikipedia, they'll have to deal with such unsavory practices.
Since you're having trouble reading between the lines, I'll explain:
1. Unfortunate client is set to prefer (not require) encryption. 2. Client connects to server. 3. Client sends STARTTLS request. 4. MITM rejects STARTTLS request. 5. Client sends AUTH command, with username and password, over unencrypted channel. 6. Server rejects unencrypted AUTH command. 7. MITM issues STARTTLS request. 8. MITM issues AUTH command with the password it just stole.
This can, incidentally, be done over any public network by a MITM. Rejecting that unencrypted AUTH command helps combat users who disable (or don't enable) encryption in their clients, simply because they'll try it once, then enable encryption when they can't send mail (hopefully it isn't too late at that point). But it does nothing against users with mail clients that are not set to require that encryption succeed. It does nothing to address the case of the ISP stripping STARTTLS requests.
Ideally the client would be correctly configured too.
If all clients were somehow correctly configured (which they won't be, because Users), then OP wouldn't have any need to configure his mail server to reject unencrypted authentication attempts in the first place.
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate.
So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?
Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?
First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it inseveralplaces.
This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.
The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.
So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.
That said, if they performed some meager sanitization, it could go a long way to improve the situation.
It's worse than that. Most browsers don't check certificate revocation lists, and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.
Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.
There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.
I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.
That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.
This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):
char *rec_p = record;// record pointer uint16_t rec_len = SSL3_RECORD_LEN;// hi! i'm ignored. uint16_t user_len = *(uint16_t*)rec_p;// user_len = user-supplied length rec_p += sizeof(uint16_t);// rec_p points to start of user payload char *buf = malloc(user_len);// allocate using user-supplied length memcpy(buf, rec_p, user_len);// copy user_len bytes from record reply(buf);// reply with said data
Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.
Most keys marked "Do Not Duplicate" are not standard keys. Assuming that the kiosk carries only certain types of blanks instead of fully machining each key from a block (likely, but unspecified in TFA), it shouldn't be able to duplicate non-standard or "security" or vehicle keys anyway.
If you happen to have a normal house key marked "Do Not Duplicate", and you really want to duplicate it anyway, ten minutes with some sandpaper will take care of that problem, and then any random locksmith will do.
Holy bad example, Batman! A guy who robs a liquor store for $100 doesn't get 20 years for stealing $100. He gets 20 years for pointing a gun at the liquor store attendant and threatening his life for personal gain. Possibly as a repeat offender.
What a lot of commenters don't seem to get is that the sort of pollution that hardcore offenders engage in over there often results in human deaths. So the potential for punishment is merely being brought in line with the crime. You won't deter serious polluters with a fine.
That said, sure, many crimes are not proportional to their sentences. No news here. While we're making improbable demands, i think the act of spitting chewing gum on the street or sidewalk should be treated as vandalism, and enforced accordingly.
It doesn't, actually. The definition of "permission" with respect to contracts has a well-established (legal) definition that is not vague in the slightest.
This. Sort of. Well, almost. You started off on the right track, anyway. But neither "top end Dell" nor "$1000 Eizo" will get you a monitor without PWM.
For the uninitiated, PWM stands for Pulse Width Modulation, and essentially, the PWM component blinks the LED backlight quickly in order to dim the brightness. The dimmer your backlight, the longer the "off" time. Sometimes, PWM use causes a perceptible flicker. What is perceptible and what isn't is subjective, however, and sometimes the flicker is imperceptible to a person, but still causes eye strain. Some PWMs blink faster than others, and faster-blinking units are generally regarded as easier on the eyes. Note that the use of a PWM isn't necessary -- LEDs _can_ dim, but since LEDs don't have linear electricity->lumens output and dimmer LEDs can experience a color shift, it's the easy way out. Most monitor backlight engineers take it.
I'm quite sensitive to PWM flicker. LED monitors especially tend to drive me nuts, so I did my research on this.
A couple of months ago, I compiled a list of no-PWM monitor options, from scouring tftcentral.co.uk, prad.de, and message boards around the internet. My criteria: - IPS, or comparable (though all TN panels would use PWM anyway) - no PWM, period -- not even really, really fast ones. - preferably non-glossy, but any options will be considered. - minimum resolution: 1920x1080
That's it. No size restrictions. These are the options I came up with: - DGM IPS-2701WPH - Dell U2713HM - HP zr2740w - Samsung S27B970D - ViewSonic VP2770-LED
[Note that the Samsung, while it doesn't utilize typical PWM tech, does fluctuate according to some tests. For this reason, I did not consider it further.]
I found it interesting that all options were 27".
I, personally, bought the HP zr2740w, and I enjoy coding on it quite a bit. It's worlds easier on my eyes than any LCD monitor I've used in the past. Newer models such as mine (which was made in late 2012) apparently have a less aggressive anti-glare coating than older versions. Fine text is crisp using either gray-on-black (my preference) or black-on-white (the web's preference). White screens do not seem at all "dirty", as some people complain about the older revision.
I'm an immigrant also, but I was polite. The limit may be a function of how annoying the customer is.
Or how little English the customer speaks, which is often related to how annoyed the service rep becomes. Or how xenophobic the service rep is. Or whether the service rep is currently having a bad day. Or any other of 3,723 possible factors.
I don't see, in any linked article (or the summary), any suggestion that Li understood the manager's English at all. The article says that she was earlier told that two was the limit, which is something that *can* be conveyed with body language in the case of a language barrier. Nowhere does any article suggest that she understood that she was not to come back. I fail to understand how you can infer that she spoke English from this.
The officers, on the other hand, had every reason to believe that she understood them, because when she acted ignorant initially, they yelled more loudly. I'm sure that cleared things up.
The summary doesn't say it (and the linked article doesn't expound), but according to http://www.dwicourts.org/drugged_driving this "night" of which they speak is a weekend night. So, Friday or Saturday. Living in NYC and riding a motorcycle (which I refuse to do nowadays on Friday and Saturday nights), I'd expect that number to be much higher, but perhaps the rest of the nation averages it out. Or perhaps many people who plan to drive with a BAC over 0.08 know where these checkpoints may lie. I did, and actively avoided them due to traffic concerns, when I did ride (sober) on those nights.
Why is everyone bashing HP and Meg Whitman for this? The purchase happened pre-Meg, and this write-off is a great decision on HP's part. There's a fair chance that the purchase decision wasn't even as poor as HP's making it out to be, and this write-off is just being maximized for tax purposes.
Hate HP for making us individual taxpayers pick up the slack, but don't hate them for being stupid (in this case).
I wonder how many people who posted comments here, thinking that streaming music analytics is a good idea, would also enable the do-not-track flag in their browsers and opt out of Google's targeted ads.
Right. And, according to TFA, none of their supplies ever went out. I live in NYC. A lot of the city lost power, sure. The transit system was knocked out, sure. There was a lot of flooding in fringe areas, where most data centers weren't. This guy is talking about NYC like it got demolished by the storm. Slashdot already did a piece on how a NYC data center mitigated power loss; reading TFS, I was hoping for a point of view from a more heavily battered standpoint. Instead, I got, "We had back-ups, and we think they work because we test them regularly, but we didn't actually have to do anything."
In theory, it works. In practice, it's a terrible idea, unless your aim is to walk out with a Mac.
I'm going to examine Best Buy, but the strategy is typical, and other large retailers, such as J&R and B&H, operate similarly.
1. If Best Buy hasn't sold its old stock yet, they put it out on the floor. If you want newer stock that _isn't_ on the floor, you have to ask for it -- but it's packed up, and you don't get to play with it.
2. Cheap laptops sell well. So Best Buy management says, "Let's put out more cheap laptops!" Then there isn't enough room for high-end laptops on the floor. That's okay, because high-end laptops don't sell well. Soon, high-end laptop sales drop even more, and management thinks that has something to do with demand.
3. Higher-end laptops that are on the floor are built with poor specs, and they're from low-class brands. Again, i imagine that this is to keep the price down.
Scenario: Bob walks into a Best Buy to look at their highest-end Windows-based laptops. They're lousy. They're made by Sony or Toshiba, and they're falling apart on the shelf. But he sees low-end Lenovos with the cheapest, lousiest screen options next to them. He looks up the model and sees that many of them are from last year. Then he looks at their Mac selection. It's current (because Apple requires it), and the screens are decent. The hardware isn't rock-bottom. He walks out of Best Buy thinking that if he wants a computer that doesn't suck, he has to get a Mac.
In reference to another reply: You want to know who's killing Best Buy? Best Buy is.
This is, in fact, how one-time passwords work. Once upon a time, RSA strengthened the security of their tokens through algorithm obscurity. The only news is that the algorithm cannot be considered obscure any longer. And this news is old. The fact that some random "researcher" learned enough of a programming language to create a program that takes a number and uses it as a random seed is not something that anyone (aside from said "researcher", and probably his proud parents) should care about.
Slashdot Mirror
The worst part about donating isn't the lingering banners (adblock can be set to take care of them easily). It's the WMF spam. I donated once, a mistake I'll never make again. Once I donated, I was automatically subscribed to a "donators" mailing list, which they used to bombard me with requests to ask my friends to donate, subscribe to a recurring donation model, etc.. Instead, I told my friends that if they donate to Wikipedia, they'll have to deal with such unsavory practices.
As a man-in-the-middle, how difficult do you think it would be to add 250 AUTH PLAIN to a cleartext server response?
Since you're having trouble reading between the lines, I'll explain:
1. Unfortunate client is set to prefer (not require) encryption.
2. Client connects to server.
3. Client sends STARTTLS request.
4. MITM rejects STARTTLS request.
5. Client sends AUTH command, with username and password, over unencrypted channel.
6. Server rejects unencrypted AUTH command.
7. MITM issues STARTTLS request.
8. MITM issues AUTH command with the password it just stole.
This can, incidentally, be done over any public network by a MITM. Rejecting that unencrypted AUTH command helps combat users who disable (or don't enable) encryption in their clients, simply because they'll try it once, then enable encryption when they can't send mail (hopefully it isn't too late at that point). But it does nothing against users with mail clients that are not set to require that encryption succeed. It does nothing to address the case of the ISP stripping STARTTLS requests.
The GNOME foundation invented the word—nay, the letters themselves, carved and finished from wordstone hewn from the deep tunnels of the earth.
s/GNOME/Apple/
s/Apple/Android/
s/Android/Windows/
s/Windows/Palm/
s/Palm/Whirlpool/
s/Whirlpool/Whole Foods/
Clearly, all trademarks should be meaningless and indefensible.
Ideally the client would be correctly configured too.
If all clients were somehow correctly configured (which they won't be, because Users), then OP wouldn't have any need to configure his mail server to reject unencrypted authentication attempts in the first place.
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate.
So, when the client sends AUTH PLAIN <b64-encoded username+password>, and your server rejects the request because it isn't encrypted, you're happy with this result?
Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?
Ehh...
First of all, this isn't new. Hell, it's in the RFC. In fact, the RFC specifically details and recommends protecting against it in several places.
This is an implementation problem, not really anything to do with OAuth 2.0 or OpenID-Connect. Authorization servers are supposed to match the redirect_uri against valid values that are registered by the client. This is inconvenient for redirecting users back to the right page, so some popular providers decided to match based on prefix or domain, instead. And some websites on the internet have open redirects (hard to believe, i know). If the client website's security is _really_ lousy^H^H^H^H^H lax, its OAuth2 callback module might also not validate the response URI when it gets the access code, and may even not strip the access code from the URI parameters when redirecting.
The service providers are supposed to require clients to register a full redirection callback. The clients can keep track of whatever page people are on with the state parameter. But those same clients, with that same terrible security, will probably get that wrong, too.
So, it's entirely a known problem, and what it boils down to is this: You can recommend best practices, but you can't fix stupid. That's why Google and Facebook are shrugging it off.
That said, if they performed some meager sanitization, it could go a long way to improve the situation.
It's worse than that. Most browsers don't check certificate revocation lists, and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.
Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.
Web-SSL was already a broken system. Now that it's been cracked open even wider, maybe we can throw it out and implement something better.
Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.
There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.
I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.
That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.
This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):
char *rec_p = record;
uint16_t rec_len = SSL3_RECORD_LEN;
uint16_t user_len = *(uint16_t*)rec_p;
rec_p += sizeof(uint16_t);
char *buf = malloc(user_len);
memcpy(buf, rec_p, user_len);
reply(buf);
Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.
Most keys marked "Do Not Duplicate" are not standard keys. Assuming that the kiosk carries only certain types of blanks instead of fully machining each key from a block (likely, but unspecified in TFA), it shouldn't be able to duplicate non-standard or "security" or vehicle keys anyway.
If you happen to have a normal house key marked "Do Not Duplicate", and you really want to duplicate it anyway, ten minutes with some sandpaper will take care of that problem, and then any random locksmith will do.
Holy bad example, Batman! A guy who robs a liquor store for $100 doesn't get 20 years for stealing $100. He gets 20 years for pointing a gun at the liquor store attendant and threatening his life for personal gain. Possibly as a repeat offender.
What a lot of commenters don't seem to get is that the sort of pollution that hardcore offenders engage in over there often results in human deaths. So the potential for punishment is merely being brought in line with the crime. You won't deter serious polluters with a fine.
That said, sure, many crimes are not proportional to their sentences. No news here. While we're making improbable demands, i think the act of spitting chewing gum on the street or sidewalk should be treated as vandalism, and enforced accordingly.
It doesn't, actually. The definition of "permission" with respect to contracts has a well-established (legal) definition that is not vague in the slightest.
This. Sort of. Well, almost. You started off on the right track, anyway. But neither "top end Dell" nor "$1000 Eizo" will get you a monitor without PWM.
For the uninitiated, PWM stands for Pulse Width Modulation, and essentially, the PWM component blinks the LED backlight quickly in order to dim the brightness. The dimmer your backlight, the longer the "off" time. Sometimes, PWM use causes a perceptible flicker. What is perceptible and what isn't is subjective, however, and sometimes the flicker is imperceptible to a person, but still causes eye strain. Some PWMs blink faster than others, and faster-blinking units are generally regarded as easier on the eyes. Note that the use of a PWM isn't necessary -- LEDs _can_ dim, but since LEDs don't have linear electricity->lumens output and dimmer LEDs can experience a color shift, it's the easy way out. Most monitor backlight engineers take it.
I'm quite sensitive to PWM flicker. LED monitors especially tend to drive me nuts, so I did my research on this.
A couple of months ago, I compiled a list of no-PWM monitor options, from scouring tftcentral.co.uk, prad.de, and message boards around the internet. My criteria:
- IPS, or comparable (though all TN panels would use PWM anyway)
- no PWM, period -- not even really, really fast ones.
- preferably non-glossy, but any options will be considered.
- minimum resolution: 1920x1080
That's it. No size restrictions. These are the options I came up with:
- DGM IPS-2701WPH
- Dell U2713HM
- HP zr2740w
- Samsung S27B970D
- ViewSonic VP2770-LED
[Note that the Samsung, while it doesn't utilize typical PWM tech, does fluctuate according to some tests. For this reason, I did not consider it further.]
I found it interesting that all options were 27".
I, personally, bought the HP zr2740w, and I enjoy coding on it quite a bit. It's worlds easier on my eyes than any LCD monitor I've used in the past. Newer models such as mine (which was made in late 2012) apparently have a less aggressive anti-glare coating than older versions. Fine text is crisp using either gray-on-black (my preference) or black-on-white (the web's preference). White screens do not seem at all "dirty", as some people complain about the older revision.
I'm an immigrant also, but I was polite. The limit may be a function of how annoying the customer is.
Or how little English the customer speaks, which is often related to how annoyed the service rep becomes. Or how xenophobic the service rep is. Or whether the service rep is currently having a bad day. Or any other of 3,723 possible factors.
I don't see, in any linked article (or the summary), any suggestion that Li understood the manager's English at all. The article says that she was earlier told that two was the limit, which is something that *can* be conveyed with body language in the case of a language barrier. Nowhere does any article suggest that she understood that she was not to come back. I fail to understand how you can infer that she spoke English from this.
The officers, on the other hand, had every reason to believe that she understood them, because when she acted ignorant initially, they yelled more loudly. I'm sure that cleared things up.
The summary doesn't say it (and the linked article doesn't expound), but according to http://www.dwicourts.org/drugged_driving this "night" of which they speak is a weekend night. So, Friday or Saturday. Living in NYC and riding a motorcycle (which I refuse to do nowadays on Friday and Saturday nights), I'd expect that number to be much higher, but perhaps the rest of the nation averages it out. Or perhaps many people who plan to drive with a BAC over 0.08 know where these checkpoints may lie. I did, and actively avoided them due to traffic concerns, when I did ride (sober) on those nights.
Why is everyone bashing HP and Meg Whitman for this? The purchase happened pre-Meg, and this write-off is a great decision on HP's part. There's a fair chance that the purchase decision wasn't even as poor as HP's making it out to be, and this write-off is just being maximized for tax purposes.
Hate HP for making us individual taxpayers pick up the slack, but don't hate them for being stupid (in this case).
I wonder how many people who posted comments here, thinking that streaming music analytics is a good idea, would also enable the do-not-track flag in their browsers and opt out of Google's targeted ads.
Right. And, according to TFA, none of their supplies ever went out. I live in NYC. A lot of the city lost power, sure. The transit system was knocked out, sure. There was a lot of flooding in fringe areas, where most data centers weren't. This guy is talking about NYC like it got demolished by the storm. Slashdot already did a piece on how a NYC data center mitigated power loss; reading TFS, I was hoping for a point of view from a more heavily battered standpoint. Instead, I got, "We had back-ups, and we think they work because we test them regularly, but we didn't actually have to do anything."
"We didn't do anything special; our power never went out."
This is perhaps the worst recommendation here.
In theory, it works. In practice, it's a terrible idea, unless your aim is to walk out with a Mac.
I'm going to examine Best Buy, but the strategy is typical, and other large retailers, such as J&R and B&H, operate similarly.
1. If Best Buy hasn't sold its old stock yet, they put it out on the floor. If you want newer stock that _isn't_ on the floor, you have to ask for it -- but it's packed up, and you don't get to play with it.
2. Cheap laptops sell well. So Best Buy management says, "Let's put out more cheap laptops!" Then there isn't enough room for high-end laptops on the floor. That's okay, because high-end laptops don't sell well. Soon, high-end laptop sales drop even more, and management thinks that has something to do with demand.
3. Higher-end laptops that are on the floor are built with poor specs, and they're from low-class brands. Again, i imagine that this is to keep the price down.
Scenario: Bob walks into a Best Buy to look at their highest-end Windows-based laptops. They're lousy. They're made by Sony or Toshiba, and they're falling apart on the shelf. But he sees low-end Lenovos with the cheapest, lousiest screen options next to them. He looks up the model and sees that many of them are from last year. Then he looks at their Mac selection. It's current (because Apple requires it), and the screens are decent. The hardware isn't rock-bottom. He walks out of Best Buy thinking that if he wants a computer that doesn't suck, he has to get a Mac.
In reference to another reply:
You want to know who's killing Best Buy? Best Buy is.
This is, in fact, how one-time passwords work. Once upon a time, RSA strengthened the security of their tokens through algorithm obscurity. The only news is that the algorithm cannot be considered obscure any longer. And this news is old. The fact that some random "researcher" learned enough of a programming language to create a program that takes a number and uses it as a random seed is not something that anyone (aside from said "researcher", and probably his proud parents) should care about.
Unfortunately, dump requires a supported filesystem. But most people forget about the incremental backup features of regular old tar(1).