Most of the sites usually considered to be secure take pretty much the approach you are describing. Or put differently, you have simply described established industry standard.
I would recommend against using an approach less secure than the one you mention. (Whether bcrypt is better or worse th...
> "Protecting the server against DoS attacks by offloading most of the computation during validation to the client. I.e. don't iterate hashing on the server side, only iterate on client side and perform last step of hashing on server."
^ for some reason, I do not trust this.
but it's just a feeling. Could someone back this up? Or even, is there a counter argument that it might be ok?
@HamZa Essentially whatever the client is presenting becomes the "password". So the attacker only has to crack that last step of hashing to gain access.
If it works (client performance and ability to run the hash on the client), client side hashing is clearly preferable over server side hashing.
@TerryChia If a client prefers to use a weaker hash the only thing they do is weakening their own account. Why should the developer give a damn about that? The client could just as easily post their password in the newspaper.
@CodesInChaos Because you are hashing to increase security. a client side hash does not increase security.
Why do you even bother to spend time hashing if you are going to make it trivial to circumvent. Always assume that a client machine has bad intentions.
@Arperum A client can only weaken their own account by omitting hashing. They already have so many ways of doing that, so deliberately rewriting their client to omit hashing strikes me as ridiculously convoluted.
@Arperum Because you can't omit the hashing when you attack somebody else's account whose used the hashing when setting the password
@Arperum If the client program contains the hashing code, it's additional effort to omit the hashing by rewriting the client with the only effect of weakening your own account. Why would anybody do that?
@CodesInChaos If I got the hash you've sent to the server somehow, I don't even need your password anymore, I just use that hash as a password. Which it actually is.
@Arperum Obviously, but that doesn't help the attacker.
They can't sniff the hash due to transport encryption, and the only efficient way of guessing the hash is performing the expensive hashfunction on the password+salt.
@CodesInChaos No, it's that from the point of view of the server, whatever the client is presenting is the "password". If I dump your database I just have to crack that "last step of hashing" to obtain what the server thinks the password is.
@CodesInChaos I'm not saying you should remove it, just that it's not really adding much to your security. You should do server side hashing, never trust a client. Client lie and decieve
@TerryChia And how do you propose to do that? By enumerating 2^128 intermediate values?
The only feasible way of producing the one-before-last hash is by starting with the password+salt and hashing them (expensive) or by sniffing it. Direct enumeration is just as infeasible as enumerating AES keys.
Doing everything except the last iteration of the hash on the client does not weaken security. If you combine it with SRP it even strengthens security.
@Arperum The hash on the client is still salted and thus non vulnerable to multi target attacks (including rainbow tables). The final hashing step is not vulnerable to rainbow tables since there are simply far too many values to compute one.
@TerryChia In a browser there are two complications. Supporting users who disabled javascript, which only matters if the rest of the application works without javascript. And performance, since the legitimate password hashing implementation must be as fast as possible in order to support many iterations.
I've inherited an old PC from my girlfriend's dad and when setting up the printer I got a bit of a surprise:
Two questions spring to mind here:
Why does Windows think my wireless keyboard is a toaster?
Why does Windows even have an icon for a toaster in the devices menu?
@TerryChia @Adnan phhhbt you're both wrong IndieGogo -> 2 Million Dollars -> don't bother delivering anything to backers -> hide amongst the huge number of shitty "never gonna happen" projects on IndieGogo that won't deliver.
@Adnan well looking at some of the projects that are on there now, I have a feeling there's going to be a lot of non-deliveries. But even on kickstarter there's projects that have taken $300k and never delivered over 3 years after closing, no update in over a year and apparently nothing that can be done about it 'cause they say they're still working on it....
@TerryChia yeah but you'd hope google had more of a clue than indiegogo backers!
> Can Kickstarter refund the money if a project is unable to fulfill? > > No. Kickstarter doesn't issue refunds as transactions are between backers and creators directly. Creators receive all funds (less fees) soon after their campaign ends. Creators have the ability to refund backers through Amazon Payments (for US projects) and Kickstarter (for non-US projects).
@TerryChia the only way they could handle it would be to manage apportioning the money out to projects and there's no way they'd want to get involved in that...
that said kickstarter/indiegogo are (i predict) in for some rough times as projects fail and the backers start howling for their money back
Do we have a standard policy on dealing with tag wiki proposals that are copied straight from Wikipedia? Are they generally acceptable/not acceptable, or a case-by-case basis?
I've heard that many people actually use their own investment money and fund their own campaigns (ask friends to do it, or do it with fake accounts) to make it look like they're successful from the beginning.
@Adnan indeed, not sure it's a scam in the sense that they're not trying to deliver the project, although can't really see why anyone would back it (especially not for 10k!!)
Suppose a given random number generator has poor entropy, and is compressible by any compression algorithm (zlib, bzip2, lzma, etc)... the obvious signs that a given RNG is a poor choice for cryptographic operations.
Specifically the issues are:
Bad entropy
Bad seed size
Failure to use multi...
Yes, this is the standard practice. Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security). As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the se...
not offering a "continue discussion in chat" option
@Terry But but but.. think of all the awesome things you can be if you were me. You'd be an amazing cook, be able to make great pancakes, get to shoot nice guns, be a douchbag and brag about how awesome you are on a public chat room
@CodesInChaos yeah, I was more talking about the silly objections that the low rep users were pointing out. I still feel a little ookie about it, if only because it makes it far more complex and puts far more ways to screw the thing up
but it CAN be done securely
and does offer some slight (in comparison to the complexity) advantages
but man are there a lot of ways you could screw it up
well, you do never trust the client, but you can make it so that work is required by the attacker either way
oh, one additional thought, the key expansion itself also has to be slow
not just the hash iterations
err
wait
may be having a brain fart
ugh, when it gets complex and non-standard enough that I start having trouble visualizing all the attack vectors in my head, I know it is getting too complicated
granted, I am running on like 5 hours of okish sleep atm
yeah, no, key expansion just has to happen after salt application
not before or after the slow part, the starting point just has to actually be part of a large random sampling to ensure a really large random intermediate pool
Are there any format standards, ideally nice clean ones, for something like a block authentication chain, e.g. suitable for verifying the authenticity of an event log? I know there are lots of Block Cipher modes, so I'm wondering if some of them leave the text in the clear and just provide chained signatures for authentication.
Ideally the signatures would be detached from the data being authenticated, so there could be multiple signature chains e.g. with different formats or from different entities.
But we've just gotten an email to our security alias titled "Vulnerability Identified" and the entire text of the email is "A vulnerability has been identified."
Oh, and the author's signature at the bottom, so we'll know who to credit, I guess.
I've inherited an old PC from my girlfriend's dad and when setting up the printer I got a bit of a surprise:
Two questions spring to mind here:
Why does Windows think my wireless keyboard is a toaster?
Why does Windows even have an icon for a toaster in the devices menu?
Suppose a given random number generator has poor entropy, and is compressible by any compression algorithm (zlib, bzip2, lzma, etc)... the obvious signs that a given RNG is a poor choice for cryptographic operations.
Specifically the issues are:
Bad entropy
Bad seed size
Failure to use multi...
