Forgot your password?

Comment: Not an inherent problem. (Score 5, Informative) 18

by kiite (#46903191) Attached to: Nasty Security Flaw In OAuth, OpenID


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.

Comment: Re:Mountain out of a molehill (Score 5, Interesting) 239

by kiite (#46710659) Attached to: Heartbleed OpenSSL Vulnerability: A Technical Remediation

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.

Comment: Not exactly a molehill. (Score 2) 239

by kiite (#46710593) Attached to: Heartbleed OpenSSL Vulnerability: A Technical Remediation

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.

Comment: Re:Situation is a Shambles (Score 5, Interesting) 239

by kiite (#46710479) Attached to: Heartbleed OpenSSL Vulnerability: A Technical Remediation

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.

Comment: Re:It could work securely (Score 1) 192

by kiite (#44106419) Attached to: Robotic Kiosk Stores Digital Copies of Physical Keys

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.

Comment: Re:A whole lot of crimes need stiffer sentences (Score 5, Insightful) 260

by kiite (#44073499) Attached to: China Says Serious Polluters Will Get the Death Penalty

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.

Comment: Re:Note PWM LED issues (Score 1) 375

by kiite (#42904089) Attached to: Ask Slashdot: What Is Your Favorite Monitor For Programming?

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,, 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:
- 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.

Comment: Re:Yes, Unauthorized export IS a crime (Score 1) 936

by kiite (#42277459) Attached to: New Hampshire Cops Use Taser On Woman Buying Too Many iPhones

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.

Comment: Re:Yes, Unauthorized export IS a crime (Score 1) 936

by kiite (#42276043) Attached to: New Hampshire Cops Use Taser On Woman Buying Too Many iPhones

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.

Comment: "16.3%... at night" (Score 1) 608

by kiite (#42055151) Attached to: With Pot Legal, Scientists Study Detection of Impaired Drivers

The summary doesn't say it (and the linked article doesn't expound), but according to 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.

Comment: tax savings galore (Score 2) 237

by kiite (#42043805) Attached to: Meg Whitman Says HP Was Defrauded By Autonomy; HP Stock Plunges

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).

Comment: Re:tl;dr version (Score 4, Informative) 50

by kiite (#42030931) Attached to: How Data Center Operator IPR Survived Sandy

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."

What this country needs is a good five dollar plasma weapon.