The only thing wrong with this thread is that we are having this on a private channel. This means that:
- all the efforts put in here will be eventually lost (into the email pit),
- we lose the ability to cross-reference (and re-read) the points made here in the future
- we don't get to view/see/learn from other points of view/knowledge/experiences,
- we don't expose the process/journey that we are taking (which is very valuable for somebody in the future faced with the same questions)
It is really painful how the current 'closed doors conversation' culture is so strong (even in a company as open and relaxed as SI)
My view is that we have nothing to lose by having these threads in a public forum, and in fact there are lots of potential good things/events/connections that we are could be missing.
The reality is that we (at SI and TM dev team) really care about what we do, our customers and the quality of the product we are creation. So what is wrong with sharing that passion with the world?
And the worse part is that by keeping the information closed, we don't maximize the talent, energy, focus, time and courage that went into those threads.
How many times you thought: "Hey, I've already written an email/post about this with a great explanation/idea/vision, but can't find it, or can't use it (since you are not sure if you can share that text)"
I'm a big believer of the power of ideas and the need to learn from the past.
The problem is that if the past is not hyperlinked, then we can't access it when it is needed.
Same thing with security knowledge, if the available security knowledge (for example how to code securely XYZ) is not available (in a consumable format) at the moment that it is needed (i.e. when the developer is writing that code), then does it (security knowledge) really exists?
:)
One of the core values of the NHS is that it be free at the point of delivery
So maybe one of our core values should be that Application Security Knowledge is available at the point of Need
:)
For references: here is my original email (last paragraph quoted above):
Look at this thread, there are already a lot of views on the topic which is not a bad thing. The challenge is in putting all this in a consumable and hyperlinkable location so that the consumer (dev or security person) can make an informed decision.
I think it is very important to have as much 'real world' scenarios in TM as possible, since that is what happens in the real-world. There is no point in having 'theoretical correct guidance' that nobody really implements (and a lot of security guidance falls into that trap). The fact that we have TM code available and are able to talk about it, is a massive asset that we should take advantage of. Ideally we should be able to point to tons of examples (i.e. this is how company xyx did it,etc..) but unfortunately we still don't have good examples to link to.
Back to the hashes, I would still say that TM's use of client side hashes is really good since it protects the passwords in the cases where TM is used on a NON-SSL mode. Which is very common.
Again unless we are prepared to ship TM in a way that completely disables SSL (a very bad idea from an evaluation, configuration and deployment point of view), we will need to accept that a lot of TM traffic will happen on pure HTTP (non SSL) traffic.
In fact this just highlights the problem with SSL. SSL is an infrastructure security measure which is decoupled from the application. Of couse that SSL is preferred and we should recommend it, but in today's world, non-SLL is still a big reality.
Now your point of checking for password complexity on the server is a good one, but I would still prefer to do it on the client (since in fact this allow for multiple policies to be easily implemented without requiring server side changes).
Again, the right way to deal with this is to find better ways to remove passwords all together from TM (for example using OAuth).
The only thing wrong with this thread is that we are having this on a private channel. This means that:
- all the efforts put in here will be eventually lost (into the email pit),
- we lose the ability to cross-reference (and re-read) the points made here in the future
- we don't get to view/see/learn from other points of view/knowledge/experiences,
- we don't expose the process/journey that we are taking (which is very valuable for somebody in the future faced with the same questions)
