On 12/28/2012 04:45 PM, Benny Pedersen wrote:
Robert Moskowitz skrev den 28-12-2012 21:30:
It is an interesting question, should this behaviour be default? It seems that Roundcube works from a default non-secured senario and expects those that want to secure it to know what to do.
it should be coded with secure in mind no matter how stupid webmasters is :)
Benny, please, note that I am not a coder or implementor (for the most part), I am a theory and standards guy specializing in secure communications. I have over a decade of fighting this battle (actually now close to 2 decades). From the get go, security 'just gets in the way' of people trying to get apps working. No matter how many venues we work in, our wins are small. We have pretty much been successful in lower level protocol designs, but once you get up to the session level you lose. Going through this right now with IEEE 11073 (Medical Device data modeling) and their reduced session layer. IETF's CORE is punted with DTLS.
So you webmasters/admins are stuck with the job, and esperienced ones like Harald are a blessing to have around and to learn from.
And sometimes an approach looks real good and works. Until that new app
comes around and does something that totally trashes your security.
Live with it and adapt.
please note that i did not say idiots, ups i did now :)
I suspect you can open as many tickets as you choose, the developers will most likely NOT take a secure by default posture.
hmm okay with me if both http and https is secure with the same php code, i dont think its should be a consern in end users to make sure its safe to use, if this is insecure by default i ask users to use there apple hardware :)
And I can show you lots of problems with apple hardware (software acutally). In fact, do you notice the few number of VPN products for iPads? Apple has only a few pet developers to limit where the bug reports come from; they are just not staffed for major support in bug tracing in parts of their stack. They try their best to keep developers in a nice, "safe" sandbox and staff accordingly.
The main consumer OS vendors are really trying to shut down 'fringe development' to lessen bug discovery and to make more money.
We (the security area in the IETF) have worked on this for years to get basic default security into protocol and application design. It is tilting at windmills.
there is so much problems in security that all users drop it and run unsecure to get it simple, now tcpdump kids can use there logins in stolen passwords / logins, we could start using non ssl imap/pop3/submission aswell to make it even better for all parts
Security IS hard. Much harder than Rocket Science (I know some real rocket engineers and they tell me that 'rocket science' is the easy part of their job). Dr. Noel Chiappa (author of ARP and many of the early stuff that made the Internet workable) once told me, "In an house of 100 windows, the crook only needs one open."
I have been part of work on the whole login/password challenge and a real challenge is how to implement a migration to a better world. Kind of like the IPv4/IPv6 transition that has been 10 years in the works. I really dislike any shared secret design; and I work with asymmetric designs, but we have the Certicom patents hanging over our heads (thought RFC 6090 SHOULD help here).
You want to see a very good alternative to a hashed password challenge, look at SAE in IEEE 802.11-2012; it was part of the 11s (mesh) addendum and finally starting to show in code bases. SAE gets around the SPEKE patent and provides a zero-knowledge based approach. We need to grow this method. Dan Harkins (SAE author) has an EAP method using SAE, so it is becoming available.
But this is just securing the front door. This cookie business is like the kitchen window being wide open for cooling the apple pie over night....
You are stuck with a rough row to hoe (a very America idiom?). But hey, it will be life time employment!