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!
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users
