Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
thomasptacek
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
thomasptacek
19y ago
Give me a fucking break. If you patch any part of the software stack on an embedded device, and then are dumb enough to apply a vendor software update to the device, you get what's coming to you. Your phone is fine: it's the same bundle of
32.
▲
by
thomasptacek
19y ago
Does it load faster than RadiusIM? Ebuddy? The Google Talk Widget? KoolIM? Aren't these things a dime a dozen?
33.
▲
by
thomasptacek
19y ago
Clearly neither system works reliably, but just to put that suggestion in context: http://reddit.com/info/2r8d8/comments vs. http://programming.reddit.com/info/2qbye/comments "Quality" sounds like a good metric until you realize that u
34.
▲
by
thomasptacek
19y ago
We take requests! I'm working on this with my partners. Thanks for the suggestion.
35.
▲
by
thomasptacek
19y ago
You are right, and this is a personal failing. Experience suggests I'm unlikely to overcome it. For the record, I don't think any of you are embarassing retards. But after reading comments here and elsewhere --- "that's OK, I'm making my sa
36.
▲
by
thomasptacek
19y ago
Even if they're just the isprint characters, that's still 74MM variants on every hash. Stop thinking about rainbow tables. Nobody is going to rainbow table your weak salted password scheme. They don't have to, because you're using native SH
37.
▲
by
thomasptacek
19y ago
Tell me all the things you parse for, and I'll name something you missed. The catch: if I do, you have to change the front page of your application to this: http://www.kare11.com/assetpool/images/0791415019_well101HDB... for at least 2 w
38.
▲
by
thomasptacek
19y ago
If you ship on Unix, use what your operating system ships with. Failing that, use bcrypt, or PHK's MD5 scheme. If you must DIY, iterate the hash function several thousand times.
39.
▲
by
thomasptacek
19y ago
I'm not saying you should be embarassed for conversing about this subject. I'm saying that if you store real people's passwords in a publically accessible web application using a single-iteration SHA1 hash scheme, you're insecure, and shoul
40.
▲
by
thomasptacek
19y ago
Consult the Wikipedia on "SQL Injection" attacks.
41.
▲
by
thomasptacek
19y ago
I don't understand why people are hyper-focusing on this one attack. Attackers have been cracking passwords, quite effectively, long before tools like Ophcrack were available. Any decent salt scheme beats Ophcrack; it doesn't take much to m
42.
▲
by
thomasptacek
19y ago
Nobody is saying you don't need to use salted passwords. What we're saying is, if your password scheme is (user, nonce, SHA1(nonce, password)), don't bother; just store your passwords in plaintext. Your users passwords are so weak (dictiona
43.
▲
by
thomasptacek
19y ago
Password cracking is an offline attack. If you think the only way you're going to lose your password table is if someone steals a hard drive or a backup, or uses a zero-day to root your whole server, you are making an extemely bad assumptio
44.
▲
by
thomasptacek
19y ago
Seriously, all three of the articles you're implicitly commenting on answer this question directly.
45.
▲
by
thomasptacek
19y ago
I'm really not sure you're talking about the same thing as, well, anybody else doing password security. Brute force incremental crackers (read: almost every password cracker ever written) don't attack the algorithmic strength of SHA1. They
46.
▲
by
thomasptacek
19y ago
Acts_as_authentable uses bcrypt.
47.
▲
by
thomasptacek
19y ago
Your hash function needs to be slow, so that incremental cracking is infeasable. This is much more important than the length of your salt. No offense, but you should read the articles you comment on.
48.
▲
by
thomasptacek
19y ago
The salt is public. If you have the password table, you have the salt. The attacker doesn't have to guess the salt with an incremental password cracker (read: almost any password cracker). The mistake you're making is your misuse of the wo
49.
▲
by
thomasptacek
19y ago
As a person who spends 3-4 days a week assessing other people's web apps, I'm well-familiar with the fact that it's a very good bet that everyone's web app is SQL-injectable, whether they've tried to stop that attack or not. For example, do
50.
▲
by
thomasptacek
19y ago
That's horribly irresponsible. Using your logic, you might as well just store the passwords in plaintext. Most people don't use different passwords for different applications, and your web application is inevitably going to expose all your
51.
▲
by
thomasptacek
19y ago
All due respect, but you shouldn't be designing password schemes. Modern password schemes are cracked using incremental crackers. This "rainbow table" stuff has totally confused the developer community. John the Ripper doesn't make a time/s
52.
▲
by
thomasptacek
19y ago
If you use the same password for your web 2.0 recipe account as your bank, etc, etc, etc. We shouldn't rationalize this stuff. All I'm saying is, don't make mistakes with your password system; use someone else's (good) password scheme.
53.
▲
by
thomasptacek
19y ago
Salt length and hash speed are orthogonal. Increasing the length of your nonces doesn't make your passwords less crackable. If this is news to you, don't design your own password scheme; use someone else's good one, so you aren't accidental
54.
▲
by
thomasptacek
19y ago
If you have to reason through or alter what you're currently doing with passwords, it's irresponsible of you to be storing passwords at all. Like it or not, your users are using the same password for your web 2.0 recipe sharing program as t
55.
▲
by
thomasptacek
19y ago
I was on the committee for Usenix WOOT, and this was one of my favorite submissions. But it has very little to do with concurrency or multicore CPUs. Watson's paper points out that where there are indirections inside the kernel (for instan
56.
▲
by
thomasptacek
19y ago
I apologize.
57.
▲
by
thomasptacek
19y ago
Can I ask why they would have had to do that?
58.
▲
by
thomasptacek
19y ago
Grow up. You compared Jottit to the iPod. Ludicrous.
59.
▲
by
thomasptacek
19y ago
You mean like... Writeboard? An application so simple that even 37 "We'll Charge You $100 For A Calendar Plugged Into An Address Book" Signals gives away for free? I wonder why Google doesn't have something just like this already... oh, wai
60.
▲
by
thomasptacek
19y ago
No, it isn't.
More ›