Reputation
34,171
Next tag badge:
617/400 score
77/80 answers
Badges
2 38 91
Newest
 Nice Answer
Impact
~2.2m people reached

Nov
15
comment help me about salting passwords
@JohnWu - what do you see as the wrong reason? Your answer meanders too much for me to figure out what you think is the problem here.
Nov
15
comment help me about salting passwords
What the questions asks about is a dictionary attack with a known dictionary of inputs. What you are defining as a dictionary attack is actually a rainbow table attack. The question is simply looking to have a set of possible inputs that you must try. This answer seems to meander and be misleading and doesn't add anything not covered in the other answers.
Nov
14
comment help me about salting passwords
@user34221 - if Eve did not have the salt, she would have to try every possible salt and dictionary combination, so yes, however this isn't practically going to happen very often, if ever, as the salt is also necessary for the hash to be verified and isn't considered secret information. The security of the hash should never depend on the salt remaining secret.
Nov
14
comment Why can SSL certificates not be free of charge?
The solution in the case of a compromised CA is that patches have to be issued to browsers that remove that CA's private key from being trusted. Another possible issue is that if you have a local compromise, an attacker can install their own root certificate and create fake certificates for any site they choose because you now trust the attacker as a CA. This is part of why the general rule is that all bets are off if your local computer is compromised.
Nov
14
comment Why can SSL certificates not be free of charge?
@DonutE.Knot - as long as the certificate has not been revoked it is safe. If they are able to compromise the private key on the server and also compromise the revocation list on the CA then there are bigger problems (for example, they could just issue another certificate with the CA's system). This has happened on a few occasions with poorly run CAs. Technically, if they are only able to block access to the revocation list, then the client is supposed to reject the certificate and the revocation list should be signed by the CA's private key, so it can't be faked without compromising the CA
Nov
14
comment help me about salting passwords
Effectively, yes. Eve must combine each dictionary word with the salt for the record she is attacking at that time. So for the user with salt 'abc' they have to try 'abc'word1, 'abc'word2, etc etc until they get a hash that matches. Then for the record with hash 'def' they have to try 'def'word1, 'def'word2, etc. This does result in a maximum of 500,000 tries for each of the 100 users or 50,000,000 tries in total.
Nov
14
comment Why can SSL certificates not be free of charge?
That shared key is then used for communication during the SSL session.
Nov
14
comment Why can SSL certificates not be free of charge?
The communication is primarily between the client and server. The server provides the certificate to the client, the client sees that the public certificate is signed by a CA that it trusts (because it has the CA's public certificate pre-installed as trusted). The client then may or may not check a revocation list (hosted by the CA) to make sure the certificate hasn't been lost. The client can then make an encryption key for the session and encrypt it with the public key of the server. The client can then send the encrypted key to the server and only the proper server can decrypt it.
Nov
14
comment Why can SSL certificates not be free of charge?
@DonutE.Knot - the easiest way is to change your hosts file on your local computer so that it resolves URLs incorrectly, but other things like DNS poisining or even hijacking a router along the route your data takes are possibilities. There are very many different ways that traffic can be hijacked because the internet is built to more or less trust participants because security wasn't a big concern when it was built.
Nov
14
comment Why can SSL certificates not be free of charge?
@DonutE.Knot - correct, the SSL certificate verifies to the client that the connection comes from a server which has the private key and the CA will only give the private key to a server that can verify it belongs to the company that has the domain. If someone tried to redirect, they would need to be able to use the private key for a trusted certificate that says they are that URL and company, but since they don't have that, your browser would reject it.
Nov
14
comment Why can SSL certificates not be free of charge?
@DonutE.Knot - the problem is how do you tell you are actually getting to google.com and not my server that I have snuck in-between your computer and google.com and have maliciously claimed is google.com. Unless some third party verifies the certificate, you have no idea if the url you entered is actually the site you intended to get to. That is the entire point of SSL certificates being signed by a certificate authority.
Nov
8
comment How reliable are device IDs provided by PhoneGap on Android and iOS?
@trejder - depends on your scenario. If you don't care about a third party listener being able to impersonate the phone it could be anything, but you should really use a cryptographic certificate that can be used in a challenge/response without exposing the phone's token to the outside world if you want to maintain a higher degree of security. You can do it over an encrypted channel and use a simple value and be ok too though. Really depends on your needs.
Nov
5
comment Untrusted central server and self-hosted/local client
except that complex javascript can self-mutate and thus it's pretty trivial to inject vulnerabilities nearly undetectably.
Nov
5
comment Untrusted central server and self-hosted/local client
It is however a valid claim to talk about people running their own servers separate from the system author, but then it could still simply be obtained from the system author's site live.
Nov
5
comment Untrusted central server and self-hosted/local client
but how do you know which client is good and which is bad if there are both out there? You can assume that the first client is good, but how do you know that it doesn't have bugs that the new client actually needs to fix to remain secure? Fundamentally, if you don't trust the author of the software, you can't trust the software. Distributing it so everyone has a different copy makes things worse, not better since now you have a bunch of different parties with potentially incompatible clients all able to claim to be the secure one. Trusting the wrong party in any case results in compromise.
Nov
4
comment Untrusted central server and self-hosted/local client
All that matters is that the server not be able to access the user's data with it's level of access.
Nov
4
comment Untrusted central server and self-hosted/local client
at that point, why not just work with a server that doesn't contain the information that is needed to access the data but is still trusted to provide routing and handling and code. The keys can remain local, but the code itself can be provided from the server since at some point you have to start trusting. If you don't trust those operating the server to write secure code, then you don't trust them to write code you run locally either, so the code being provided doesn't matter as long as we know the server is authentic.
Nov
4
comment Untrusted central server and self-hosted/local client
ok, sure, but you still need to get the client from somewhere and that server ends up being trusted since it is the source of the client. The only way around that would be to use existing technologies and let someone build their own client based on an open protocol.
Nov
4
comment Untrusted central server and self-hosted/local client
If you don't trust the server providing the client, what is to prevent the server from altering the client to send the information back to it? If they have to get the client elsewhere, why limit it to web technologies when native can do a far more secure and efficient job?
Oct
25
comment Securing an automatic updater
This discounts the possibility of the server itself being compromised. If the attacker can make the update server their personal playground, then you still don't want all the clients to be made vulnerable.