thirsteh

44 ms·

421.
by thirsteh 13y ago
http://throwingfire.com/storing-passwords-securely/#notpassw... http://codahale.com/how-to-safely-store-a-password/
422.
by thirsteh 13y ago
Anti-virus protection is a mediocre "solution", or a "decent component in a larger security system" at best. It's marketed as being a silver bullet; "all you need to stay 100% safe." Understandable--it mak
423.
by thirsteh 13y ago
You hit the nail on the head.
424.
by thirsteh 13y ago
> Earliest defense for making sure windows doesn't get infected - NAT, don't leave a windows machine on a public IP... Yes, but a basic one. You'd prevent something running on port X from being exploited directly. Doesn&#x
425.
by thirsteh 13y ago
As far as you know. Even the dumb malware writers don't write stuff that pops up floating skulls and "OwNEd by CyBeRKiLLeR" messages anymore. It's all about staying on the machine, and staying silent. I hate this "I
426.
by thirsteh 13y ago
It's not really an ethical problem, just an estimation. If SML was the only similar language, surely a lot more people would be using it.
427.
by thirsteh 13y ago
Okay, but that has nothing to do with Yesod vs. Snap, really. You don't have to use Persistent in Yesod--it's just as easy to use HDBC if you want to.
428.
by thirsteh 13y ago
F# might already be more popular than both, but it's hard to tell for sure.
429.
by thirsteh 13y ago
Snap has the same problem. If anything, Yesod is where you're the least on your own because of the Persistent integration.
430.
by thirsteh 13y ago
Most of the people who would be using SML are using Haskell, hence why Robert Harper is so bitter, constantly writing blog posts about how much "Haskell sucks", and how "unsafe" it is. edit: or OCaml, or F#.
431.
by thirsteh 13y ago
You're both correct. It's been in the docs for io.Copy for a long time, and was only recently added to the http docs.
432.
by thirsteh 13y ago
http://golang.org/doc/go1compat.html 'go fix' was mainly used before Go 1, but it would be useful again for e.g. a Go 2.
433.
by thirsteh 13y ago
or "I passed an fp to your function, and you called close() on it. How dare you!?" :)
434.
by thirsteh 13y ago
That is pretty funny, but it doesn't really change anything. It's unfortunate that it called Close() without at least giving proper notice, and most people will probably agree that in a perfect world where we could start over with
435.
by thirsteh 13y ago
> That is SO disturbing... They don't even check whether the parameter implements another interface, they do the check directly on the method by callin it... That's so ugly... That's incorrect. The code you see at the top:
436.
by thirsteh 13y ago
I agree. I think I edited my comment to specify that it's a much more unsafe assumption just before you posted your comment.
437.
by thirsteh 13y ago
It depends on what your definition of "fundamental problem" is. If being able to treat a value differently than it was received, or to perform computations that you shouldn't be able to, e.g. impure actions inside a pure func
438.
by thirsteh 13y ago
> So if I implemented my own object with a Reader interface and passed it to this HTTP library, could it find some other method on my object named Close() and it could call it? Yes, and that's what's happening here. It can try
439.
by thirsteh 13y ago
An example: http://golang.org/src/pkg/io/io.go?s=11741:11801#L336 Line 336. io.Copy takes a writer and a reader, but actually asserts whether they implement ReaderFrom/WriterTo, then use their methods, R
440.
by thirsteh 13y ago
Purpose.
441.
by thirsteh 13y ago
You have IDEs installed on your production servers...?
442.
by thirsteh 13y ago
Chrome supports public-key pinning via HTTP responses: https://code.google.com/p/chromium/issues/detail?id=78369 . I'm not sure about the other browsers. https://tools.ietf.org/html/d
443.
by thirsteh 13y ago
It doesn't require that at all. You could simply strip the SSL and present a HTTP version of the page, and most people would be none the wiser. Or you could redirect to e.g. www.facebook23.com and have them log in there, with a nice li
444.
by thirsteh 13y ago
I think that's an unreasonable assumption. It's far more likely that a CA is compromised than an ISP. Also, don't underestimate the power of e.g. sslstrip. Most users enter "google.com", not " https:/&#x2F
445.
by thirsteh 13y ago
Well, only to the extent that the PKI model is trustworthy. If somebody can perform a MITM attack against you, you are wholly reliant on them not being able to generate a certificate for the domain you're looking at. It's better,
446.
by thirsteh 13y ago
https://www.youtube.com/watch?v=HPl10L40pBM
447.
by thirsteh 13y ago
If you think "m00n" vs. "moon" or "The" vs. "the" matters, you're not paying attention. A memorizable, but randomly composed string of words all in lower-case ASCII is significantly stronger than
448.
by thirsteh 13y ago
That's why I said alleviate, not solve. HSTS is a bandaid at best. The bottom line is regular people don't know the difference between entering "www.mybank.com" or " https://www.mybank.com" , they nev
449.
by thirsteh 13y ago
He's right--you're just not talking about the same thing. You're saying that if somebody forges a non-HTTPS page so that it doesn't POST to the original secure page, then you can trivially intercept the credentials, an
450.
by thirsteh 13y ago
Actually, if you go to reddit.com/login directly, you get http://reddit.com/login , not https://reddit.com/login , which means anyone can forge the login page. This is the problem HSTS was designed to be

More ›