On 080110 at 20:00, Alexander Mueller wrote:
Adding mechanisms always adds complexity, not only in terms of code but
also in terms of things the admin should consider to setup a secure
system. So the added complexity should be worth something.
Correct, however I'd say the added complexity
Boris Zbarsky wrote:
Alexander Mueller wrote:
However HTTPS does not prevent that the Administrator of the
destination server is acquiring the actual plain text data.
So the .value of this input would already be hashed? Otherwise, this
argument fails: the page can just grab the value and
Jean-Marc Desperrier wrote:
Could be nice to do that, so there would be no way from javascript to
get the original value the user has typed.
Thats one point, however as you wrote if the page itself is altered
there is already a much bigger problem, therefore the primary idea
behind the
On 080110 at 12:20, Alexander Mueller wrote:
Could be nice to do that, so there would be no way from javascript to
get the original value the user has typed.
Thats one point, however as you wrote if the page itself is altered
there is already a much bigger problem, therefore the primary
Steffen Schulz wrote:
So its not working against MITM or impersonating the server.
No, it definitely does not. This is what certificates are for.
The plaintext pw is not transmitted and can not be read by, say,
XSS-stuff. But why would anybody care about the plaintext pw if one
only
Alexander Mueller wrote:
This question is covered by my initial posting :).
Not really. And yes, I did read what you posted.
But basically this is still to be discussed
I'm just pointing out that if this is to solve the use cases you claim it
solves, there is nothing to discuss. There is
Boris Zbarsky wrote:
Not really. And yes, I did read what you posted.
Here we go :)
I am only aware of one, the way how client side access (via JavaScript
for example) to a hash field is handled. While write access should
probably always set the passed value, read access is a bit more
Steffen Schulz wrote:
Adding mechanisms always adds complexity, not only in terms of code but
also in terms of things the admin should consider to setup a secure
system. So the added complexity should be worth something.
Correct, however I'd say the added complexity in this case (which isnt
Sorry, if I might have chosen the wrong group, but as my issue is also
security related I thought this group is still the best to choose. If
there is a better, please let me know. Thank you.
I sent this message already to a W3.org mailing list, but consider it as
important to have it
Alexander Mueller wrote:
However HTTPS does not prevent that the Administrator of the
destination server is acquiring the actual plain text data.
So the .value of this input would already be hashed? Otherwise, this argument
fails: the page can just grab the value and do whatever it wants
10 matches
Mail list logo
