5,026 reputation
1622
bio website
location
age
visits member for 2 years, 11 months
seen Apr 17 at 15:05

Apr
15
awarded  Nice Answer
Mar
30
comment How to use OpenSSL generated keys in Java?
@miho, no, I was just talking of ways to read them. PEMReader will try its best to read anything it can. A certificate has more information than just a public key (it binds a public key to an identity and other attributes).
Mar
23
comment What is the potential impact of these SSL certificate validation vulnerabilities?
@RahilArora, "But since badguy.com does not have the private key which was used to sign the cert for goodguy.com". Not sure you meant it the way you wrote it here. The private key used to sign the cert for goodguy.com is that of the CA. If badguy.com has the private key of the CA, it can re-issue any cert it wants (a very bad scenario). Assuming that's not the case, the private key badguy.com doesn't have is the private key that matches the public key in goodguy.com's cert (again, this isn't the key with which the cert was signed). Indeed, this will prevent the handshake to work.
Mar
23
comment What is the potential impact of these SSL certificate validation vulnerabilities?
@RahilArora, hostname verification is about checking that you're talking to the server you intended, and not an imposter, even if the imposter presents a legitimate certificate issued to its name (with its own private key). Let's say goodguy.com (at 10.0.0.1) and badguy.com (at 10.0.0.2) both have a valid cert, the clients wants to connect to goodguy.com, but is redirected by a MITM attack that spoofs the name and points goodguy.com to 10.0.0.2. This will show a valid cert, but for badguy.com. This cert will not fail the PKI verification, but would fail the name verification.
Mar
23
comment What is the potential impact of these SSL certificate validation vulnerabilities?
@RahilArora. well, that's the point of hostname verification: to make sure the host hasn't been spoofed. If you assume that the certificate was only issued to the legitimate host name (as should be done by the CA), if someone spoofs the host name, they won't be able to provide you with the right cert. Hence, the client needs to verify the host name in the cert matches the name requested.
Mar
14
revised Digital Signatures of XML, PDF and Office Documents on every platform
Improved formatting
Mar
14
comment Digital Signatures of XML, PDF and Office Documents on every platform
It's an interesting appliance, but isn't it a bit at odds with what you said in this other answer ("[..] your private key is the sine qua non of your identity. You don't send it anywhere)? The problem here is that your private key isn't in your hands. Unlike smartcards, you're effectively delegating the authentication to whatever mechanism was used with this box, not necessarily providing as good a (legal) level of assurance as smartcards and private keys. This being said, it's all about trade-offs, and your approach doesn't sound bad at all.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
@suzzy-delta, ah, sorry, I deleted my comment because I thought I was nit-picking...
Mar
12
answered Is it ok to send user's private key away, even if protected with a SSL channel?
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
Yes, and that can be very tricky to implement in the browser, if possible at all...
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
Please don't post both here and on SO, flag the question to be migrated instead.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
That API will not actually give you the private key, it will only let you use it to sign something, the processing being done on the card itself. So, any plan to send the private key somewhere or have some code (that doesn't use this API) use it wouldn't work.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
By the way, most Smartcard mechanisms don't let you get access to the private key itself, so you'd somehow have to interface with the signature API for the card anyway.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
Not really. And again, half of this problem isn't technical.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
Don't do JS crypto. You won't be able to prove to the user what your code does (it could still send the key). As far as I'm aware, some of the WebCrypto project was trying to address some of these issues (e.g. by letting some JS code use the private key stored in the browser without letting it out), but it's not quite ready yet, and it doesn't solve all the problems (e.g. proving the the users what they're signing with that private key).
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
@user3411342, you're not talking of a password to access a resource (which in some cases may not be sent to the resource you're trying to access, by the way, including here on SO), you're talking about signing here. The purpose is completely different.
Mar
12
comment Is it ok to send user's private key away, even if protected with a SSL channel?
This question appears to be off-topic and would probably be better on Security.SE.
Mar
12
answered Is it ok to send user's private key away, even if protected with a SSL channel?
Feb
8
comment Standards for encrypting passwords in configuration files?
It really depends on the type of application we're talking about. I'd suggest most applications that require a password in a configuration file (as opposed to typed in by the user) are services, aimed to be running unattended on a server. In this case fingerprints or other user-based methods are not particularly useful (by lack of users to provide them). Some forms of OS-based protection (as you suggest) can help a little, though.
Feb
8
comment How to do Ajax securely?
Good points in general, but mysql_real_escape_string certainly isn't the right method to protect against MySQL injection attacks in PHP.