Stephane

That isn't how I understand it. For me security theater is when there are measures in place that are designed to make the public/user/management feel secure while not actually implementing effective security. That isn't the case here: as far as we can tell, using the username along with salt isn't strictly necessary for the security of the password but it doesn't make the system insecure or even make it feel more secure: it just adds some properties to it (some of which might be desirable but out of scope of the question)

@SeanBurton It really depends on the context (which we don't have). For instance, if there is no way to obtain a globally unique salt but we're sure there the username is blobally unique, the using username+salt is a valid way to make sure the salt is unique (you can simply use a counter inside the user's record). It's just a technical quirk that cannot be explained with the very limited facts we have at our disposal.

Second problem: this isn't "security theater", at least not taken in isolation. The addition of the user name to the hashed key doesn't help with security but it doesn't hurt either. As long as the salt is correctly generated, the algo is pretty much correct (athough, of course, it isn't sufficient for ensuring security of the password, but that's something else).

I have two problems with your answer: first, your representation of a password is wrong from the application point of view: a password is NOT considered unique (that why you need a distinct salt with every password).

I'll write something when I have a moment tomorrow

They your physical security fails and you have no solution.

What's wrong with simply gluing the mouse/keyboard to the cables ? Why should the user have admin rights on the machine?

@Adi +1

Anyone has a link for the /correct/ definition of a secure hash function ? For once, Wikipedia is failing me...

'morning

'morning

Ah, my favorite security metalhead is here. Howdy ?

^morning folks

That wouldn't give me the specific malware^h^h^h^h^h library I need

Oh well. Might as well write it myself.

Damned... sourceforge is down and I need to download a lib...

@AviD That's specism!

^^

Anyone has information on how to use a HSM in a cloud-based environment (IaaS) ?

Not my sandbox

No idea, really

'morning folks

@DavidFreitag See ? Night owl happens

Or evening

It /might/ be the afternoon for some, you know ?

(or whatever)

'morning

Hello folks

I was wondering if it was on topic, really... And if it wasn't where to send the guy

Funny... I was going to ask about this question too...

Hiya

nasa.gov/topics/technology/features/star_trek.html ??

@AviD I'm not sure the tag will carry over gracefully :P

That sucks :P

The sister of my GF lives 15 km from Clisson: there really is no reason for us not to go to hellfest

Maybe one day I'll manage to see him on stage

Nice :) I hope he has fun

I'm also saying that it could be a feature of a full-fledged product but, except in very specific case, it's not going to be a killer one

I'm not saying having a dedicated code signing system isn't a good idea, I'm saying that the management overhead and additional risk created by changing the code signing tool to use a distributed system instead of being local only is completely out of scope with the benefit

(and again, sorry for asking what your experience is. Please believe me when i say it is a honest question and I'm not attempting to "bully you" out of the conversation)

(sorry... it's time for me to go. I'll check your answer tomorrow)

I'm afraid that I'll have to call you up on your experience here: do you have any experience in project management ? In particular in the security area ? I'm asking because you sound like someone who doe not gasp the complexity (and costs) associated with such a project.

But it's not a project that should be debated here: this isn't the place for that and it would be too long a discussion.

if it's for multiple instances (i.e. a project), then things are different: it can be done, it can be done securely (if you have the right people and enough resources) and it would actually make sense (since that is a problem that a LOT of people are confronted with)

If it's for a single deployment instance, it doesn't make economic sense to do it right. In fact, the only way to do it at all is cutting so many corners and ignoring so many future issues than no same project manager would approve it

If you want an analogy, here is one: it's like changing a screw on a satellite. Changing the screw is simple. Doing so in a space suit in micro-gravity is much harder and getting someone in position to do that requires millions of dollars and thousand of workers.

No, we can't. That's what I^'ve been telling you all along: writing the code is simple. Building and maintaining a secure product around that change isn't. What makes it hard isn't the hash-signing code, it's the way it's transfered (securely) wbetween two system, it's the side effect such a change will have on the code signing code base, it's the fact that all of that has to be taken into account

Not unless that is a one-off project (in which case you can't make assumption of how it'll be used).

You can mess that up in a large number of way: since you're not checking the code, just the hash, you need to have a high confidence on where that hash comes from (that's just an example).

No. Please, don't suggest to people they start tinkering with crypto code, especially for a one-off project. It's the road to unmaintained, unmaintainable and vulnerable operation. I'm not saying it can't be done (in fact, I've checked my own code signing tools to see if I could modify them in such a way) but for production work, just don't.