91–100 of 136 posts
Earlier quoted context omitted.
I don't want to be liable if one of my servers is hacked and someone's bank account gets accessed because of it. Don't store user passwords in plaintext.
and hash the passwords on the browser.
(Assuming you are concatenating it with a server-provided random value before the hashing.)
Of course the password is in plaintext. Logins are done via HTTP, not via HTTPS. You know, there isn't that little yellow lock thingy in the bottom left corner of the window? Is this really news to anyone?
There are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html )
Avoid sending a plaintext password by using HTTPS. It's the easiest way.
Earlier quoted context omitted.
Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions wit…
be aware of the fact that several of the top security firms will demerit your app for doing it Speaking as FreeBSD Security Officer: Several of the top security firms provide ratings which reflect the quality of their checklists more than the quality of the security in the systems they're assessing. The FreeBSD security team recently dealt with a case of "if you don't fix this, people using FreeBSD will lose marks on…
Second, seperate PCI auditors out from security audits (though Hacker News readers should be familiar with both). I agree with your sentiment regarding PCI auditors. (PCI, for those who don't know, is the Payment Card Industry standard you get audited against if your application accepts credit cards).
Third: like it or not, when you get dinged on a report like that, you can lose a sale. "Hah-hah!", Colin says. "Screw the auditors!" But Colin, and FreeBSD at large, loses nothing from failing an audit. Want some horror stories about people who do lose?
Earlier quoted context omitted.
Care to elaborate?
There was a recent "security issue" reported to us whereby an attacker who could specify a printf format string could cause a buffer overflow. We don't consider this to be a security issue since if you're allowing an attacker to specify a printf format string, you've got much bigger problems already -- this "issue" doesn't make things any worse.
I'd elaborate, but I don't know the context of the finding you were dealing with. If it was, "FreeBSD needs to get rid of the %n token", the auditor was right, and you were wrong. I'd be surprised if it was that simple, though.
Earlier quoted context omitted.
No, because you're ignoring the fact that one of the 15-odd places that an attacker can bust up to redirect traffic to their own servers is the "observe all packets" vantage point, which allows them to predict DNS XIDs and source ports. I know you're smarter than this, Colin. I think you're being pedantic. Would you advise anyone on this message board any differently than me ? I think you already said "no".
Would you advise anyone on this message board any differently than me? I think you already said "no". There are two parts to giving advice: Helping people with their immediate question, and helping people better understand the field in question so that they won't need your advice the next time. You told people that what they were talking about doing was a bad idea, which I agree with; but the explanation you gave was…
Earlier quoted context omitted.
you are saying that if someone is encrypting the password using RSA in javascript and then using the hash to exchange the password between server/client, is volnerable because someone can interfere in the traffic and change the javascript served to the user, so that the password is sent in plaintext and therefore steal the password? then why meebo and other sites practise this method without security problems?
The canned argument is: No known security problem does not mean no security problem.
Earlier quoted context omitted.
That adds no security at all . Security is not an obstacle course.
Security is nothing but an obstacle course. The only time security is not merely an obstacle course is when you completely destroy the thing you're trying to protect. This is fundamentally something everyone needs to understand about computer security-- it's all about creating bigger and harder obstacles (including literal, physical obstacles). You can never absolutely secure something while it exists.
Earlier quoted context omitted.
and hash the passwords on the browser.
You can't have it both ways. If you are hashing the password before it is sent from the client to the server, you need the raw password on the server side. (Assuming you are concatenating it with a server-provided random value before the hashing.)
You'd be right to point out that this is a lot of silly acrobatics to go through to avoid a single SSL login page.
use clickpass
Actually - don't. http://img223.imageshack.us/img223/3784/clickpasskf8.png http://codefromthe70s.org/sslblacklist.asp If they don't care about the security of their web interface, do you really want to entrust them with your passwords ?