New Input type proposal

Discussion in 'HTML' started by Alexander Mueller, Jan 9, 2008.

  1. Hi,

    the reason behind my email is the proposal of a new Input type named "hash"

    <input type="hash" />

    I am now going into detail about why I'd consider it as important and
    technical information as well as comparisons to current techniques.


    What should it do and be?
    -------------------------
    Visually it can be identical to the known "password" type (a textbox
    masking its characters). The major difference would be its technical
    implementation respectively its output/result to the server.


    What would be those differences?
    --------------------------------
    An input field of the type "password" transmits its content, just as any
    other regular textbox, unencrypted to the server.

    An input field of the type "hash" should hash the given text and
    transmit only the hash to the server.


    What would be the advantages?
    -----------------------------
    As mentioned, a password field only masks its text (so that it cannot be
    read by bystanders) but does not actually encrypt or hash it, in order
    to provide a secure transmission.

    This does not only mean that the given text is transmitted in plain text
    over the network (unless SSL is used) but also that the owner or
    administrator of the destination server can always reveal the actual
    password. Further it is making replay attacks possible or at least much
    more simple.


    What would be the exact technical implementation?
    -------------------------------------------------
    A hash input field would be defined similarly to a password field via

    <input type="hash" hash="md5" salt="" replaysalt="" />

    - The first attribute (type) would indicate that a hash field should be
    displayed.

    - The second attribute (hash) would indicate the hash algorithm to be
    used (md5 in this example or also sha1 or any other available on the
    client).

    - The third attribute (salt) would be an optional (but recommended) one,
    which should provide the result with the typical "hash salt" (to prevent
    precalculated tables). A site using a salt would always need to indicate
    the same salt, in order to get the same result.

    - The fourth attribute (replaysalt) would be an optional attribute as
    well, very similar to the third. However in this case the salt should be
    randomly calculated on each request and stored on the server side (via
    sessions for example). It is applied to the hash result of the content
    and the general salt. Its primary use is to prevent replay attacks.

    Note: The replay salt should only be used on read or verification
    processes (like a logon) as otherwise (upon setting the password for
    example) the server would never be able to determine the original or raw
    hashcode.


    Why a hash field if SSL already provides secure transmissions?
    --------------------------------------------------------------
    It is correct, that HTTPS provides a secure way between the client and
    the server. However HTTPS does not prevent that the Administrator of the
    destination server is acquiring the actual plain text data. A hash input
    field would do this. Additionally it provides a semi-encryption as well
    as replay protection to non-SSL connections.


    Are there any open technical or security issues?
    ------------------------------------------------
    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
    difficult. Should the returned value be the computed hash or the actual
    value? Although I tend to the former, this should still be discussed.
    Related to this would be whether key event handlers should be called or
    not (they could be used to reveal the entered text).

    Should there be other concerns, I'd really welcome opinions.




    Concept Implementation
    ----------------------
    I have developed a first very basic extension for Firefox 2. The
    functionality as mentioned here is already implemented, however it does
    not introduce a "hash" type but rather extends the "password" type (by
    applying a hash to all password fields with a given hash attribute).

    You can find "Hash Input" at http://www.alcomp.net/hashinput


    Please let me know any comments or suggestions you have.

    Thank you,
    Alexander Mueller
    Alexander Mueller, Jan 9, 2008
    #1
    1. Advertising

  2. Alexander Mueller

    J.O. Aho Guest

    Alexander Mueller wrote:
    > Hi,
    >
    > the reason behind my email is the proposal of a new Input type named "hash"
    >
    > <input type="hash" />
    >
    > I am now going into detail about why I'd consider it as important and
    > technical information as well as comparisons to current techniques.


    I can't see any extra advantage of your input has, more than it will just
    consume more bandwidth for transporting the data. The has type will always be
    the same for a site, as the passwords will always be stored in that type, a
    site that uses md5 hashed passwords will never request a sh1 hashed password,
    as then they can't validate the password is correct.

    The method will be predictable and complicated to use and just gives a false
    feel of extra security.

    --

    //Aho
    J.O. Aho, Jan 9, 2008
    #2
    1. Advertising

  3. J.O. Aho wrote:
    >
    > I can't see any extra advantage of your input has, more than it will just
    > consume more bandwidth for transporting the data.


    Well, I listed the advantages in the original posting. Please reread it
    again to see what I am trying to accomplish with the hash type.


    > The has type will always be
    > the same for a site, as the passwords will always be stored in that type, a
    > site that uses md5 hashed passwords will never request a sh1 hashed password,
    > as then they can't validate the password is correct.


    I never talked about a mixture of hash types.

    It is about the secure transmission. The hash for a password will never
    be the same for a site but only for identical passwords (which is a
    required behaviour).

    >
    > The method will be predictable and complicated to use and just gives a false
    > feel of extra security.
    >


    Can you explain why? The only difference is that the hashing occurs
    locally and so gives a much better security to the actual data. Its
    neither more predictable nor complicated than the current solution.


    Alexander
    Alexander Mueller, Jan 9, 2008
    #3
  4. Alexander Mueller

    richard Guest

    On Wed, 09 Jan 2008 18:23:48 +0100, Alexander Mueller
    <> wrote:

    >Hi,
    >
    >the reason behind my email is the proposal of a new Input type named "hash"



    You have posted this "email" to a usenet newsgroup which is not
    maintained, or staffed by any one particular company or organization.

    You would need to impose your request on the creators of each
    individual browser. IE, FF, opera, pan, slrn, xnews,xananews and so
    on. Along with maybe trying to convince the w3c.org people to make it
    a viable include.

    Then after a few years, it might get developed. However, no guarantees
    that it will.
    richard, Jan 9, 2008
    #4
  5. J.O. Aho wrote:
    >
    > I can't see any extra advantage of your input has, more than it will just
    > consume more bandwidth for transporting the data.


    As to the traffic, yes, it will generate more traffic as long as the
    actual password is shorter than the hash (32 bytes for MD5, 40 bytes for
    SHA1). But considering only a 5 byte long password I would say the extra
    traffic of 27-35 bytes is worth the added security (some HTTP headers
    often take more).

    Alexander
    Alexander Mueller, Jan 9, 2008
    #5
  6. richard wrote:
    >
    > You have posted this "email" to a usenet newsgroup which is not
    > maintained, or staffed by any one particular company or organization.


    The "email" happened because I took the text straight from a copy which
    was sent to w3.org.

    >
    > You would need to impose your request on the creators of each
    > individual browser. IE, FF, opera, pan, slrn, xnews,xananews and so
    > on. Along with maybe trying to convince the w3c.org people to make it
    > a viable include.


    I did, see above ;)

    >
    > Then after a few years, it might get developed. However, no guarantees
    > that it will.


    Well, for Firefox there is already a concept implementation :).

    Alexander
    Alexander Mueller, Jan 9, 2008
    #6
  7. Alexander Mueller

    J.O. Aho Guest

    Alexander Mueller wrote:
    > J.O. Aho wrote:


    >> The has type will always be
    >> the same for a site, as the passwords will always be stored in that
    >> type, a
    >> site that uses md5 hashed passwords will never request a sh1 hashed
    >> password,
    >> as then they can't validate the password is correct.

    >
    > I never talked about a mixture of hash types.
    >
    > It is about the secure transmission. The hash for a password will never
    > be the same for a site but only for identical passwords (which is a
    > required behaviour).


    As you mentioned your system would prevent the administrator from knowing your
    password, then the password has to be hashed already at the site, and
    therefore the hashing has to be the the same in the form as on the site, or
    else you would always fail the login or the site has to spend long time with
    cracktools to be able to find out the password and then has it the way it's
    hashed on the site.


    --

    //Aho
    J.O. Aho, Jan 9, 2008
    #7
  8. J.O. Aho wrote:
    >
    > As you mentioned your system would prevent the administrator from knowing your
    > password, then the password has to be hashed already at the site, and
    > therefore the hashing has to be the the same in the form as on the site, or
    > else you would always fail the login or the site has to spend long time with
    > cracktools to be able to find out the password and then has it the way it's
    > hashed on the site.


    Sorry I dont really know what you are exactly meaning.

    Again, please reread my initial posting, I guess everything should be
    clear then :). The system wouldnt know the plain text password (which it
    doesnt need) but only the hash code. This can then be compared to the
    stored hash code. The only difference is the computation of the hash
    happens locally - no brute force, no same passwords.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #8
  9. Alexander Mueller

    Jeff Guest

    Alexander Mueller wrote:
    > J.O. Aho wrote:
    >>
    >> As you mentioned your system would prevent the administrator from
    >> knowing your
    >> password, then the password has to be hashed already at the site, and
    >> therefore the hashing has to be the the same in the form as on the
    >> site, or
    >> else you would always fail the login or the site has to spend long
    >> time with
    >> cracktools to be able to find out the password and then has it the way
    >> it's
    >> hashed on the site.

    >
    > Sorry I dont really know what you are exactly meaning.


    I think he's talking about the salt. Do you pass the salt with the
    form submit, if you do, what is the security advantage?

    All this looks a bit like unix password encryption where no one knows
    the password, only if it is wrong. What would the application be?

    Jeff
    >
    > Again, please reread my initial posting, I guess everything should be
    > clear then :). The system wouldnt know the plain text password (which it
    > doesnt need) but only the hash code. This can then be compared to the
    > stored hash code. The only difference is the computation of the hash
    > happens locally - no brute force, no same passwords.
    >
    > Alexander
    Jeff, Jan 9, 2008
    #9
  10. Jeff wrote:
    >
    > I think he's talking about the salt. Do you pass the salt with the form
    > submit, if you do, what is the security advantage?


    A salt is always used to have a hash which is different from the regular
    hash (to prevent precomputed hash tables). In case of salt, it certainly
    always have to be the same.

    As to the replay salt, this would only be used to prevent replay attacks
    and would or better should always be differently. Of course it wouldnt
    be used to store the password hash.

    >
    > All this looks a bit like unix password encryption where no one knows
    > the password, only if it is wrong. What would the application be?


    Well, yes, hashes are used in Unix too, but it is a general solution and
    most websites use a hash to store passwords with the exception that the
    server is generating the hash.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #10
  11. J.O. Aho wrote:
    > Alexander Mueller wrote:
    >> Hi,
    >>
    >> the reason behind my email is the proposal of a new Input type named "hash"
    >>
    >> <input type="hash" />
    >>
    >> I am now going into detail about why I'd consider it as important and
    >> technical information as well as comparisons to current techniques.

    >
    > I can't see any extra advantage of your input has, more than it will just
    > consume more bandwidth for transporting the data. The has type will always be
    > the same for a site,


    The attribute tells the *browser* what kind of hash to create.

    > as the passwords will always be stored in that type, a
    > site that uses md5 hashed passwords will never request a sh1 hashed password,
    > as then they can't validate the password is correct.


    The browser doesn't have pre-existing knowledge that such-and-such site
    uses MD5 hashed passwords (though a default hash method could be defined
    in the standard, just as there is a default value for the enctype
    attribute of the form tag).
    Harlan Messinger, Jan 9, 2008
    #11
  12. Alexander Mueller wrote:
    > J.O. Aho wrote:
    >>
    >> As you mentioned your system would prevent the administrator from
    >> knowing your
    >> password, then the password has to be hashed already at the site, and
    >> therefore the hashing has to be the the same in the form as on the
    >> site, or
    >> else you would always fail the login or the site has to spend long
    >> time with
    >> cracktools to be able to find out the password and then has it the way
    >> it's
    >> hashed on the site.

    >
    > Sorry I dont really know what you are exactly meaning.
    >
    > Again, please reread my initial posting, I guess everything should be
    > clear then :). The system wouldnt know the plain text password (which it
    > doesnt need) but only the hash code.


    OK, so the password has been left out of the server side entirely.
    Instead, to access the application you need the hash value, and the
    server administrator has access to *that*. So just substitute the word
    "password" for the word "hash" and the server administrator is now able
    to intercept the value of the hash that will give him access to the
    application.

    The point of an application storing a hash instead of the original
    password is that it only accepts the password for authentication,
    computing its hash when the it's provided and comparing it with the hash
    it has in its user lookup table. If someone hacks the user table and
    finds the hashes, it won't do the hacker any good because the
    application doesn't provide any interface for accessing the system by
    providing the hash directly. If the hacker submits the hash as though
    it were the password, the application will hash the hash, and the
    computed rehash won't match the stored hash. The application has to see
    the password itself before it will grant access.
    Harlan Messinger, Jan 9, 2008
    #12
  13. Harlan Messinger wrote:
    >
    > OK, so the password has been left out of the server side entirely.
    > Instead, to access the application you need the hash value, and the
    > server administrator has access to *that*. So just substitute the word
    > "password" for the word "hash" and the server administrator is now able
    > to intercept the value of the hash that will give him access to the
    > application.


    Correct, but the Administrator always has access to the application
    under any user account, if he wants. The point is, he does not have
    access to the actual password (nor does anyone using a sniffer).

    >
    > The point of an application storing a hash instead of the original
    > password is that it only accepts the password for authentication,
    > computing its hash when the it's provided and comparing it with the hash
    > it has in its user lookup table.


    Sorry, but thats not exactly the point. For the application it wouldnt
    matter if it has to compare the hash of a given password with a stored
    hash or simply the given plain text password with a stored plain text
    password.

    The point is to add security against attackers - as you mentioned - as
    well as, partly, against the Administrator, so that he cannot simply
    reveal the user password, which is currently possible however.

    > If someone hacks the user table and
    > finds the hashes, it won't do the hacker any good because the
    > application doesn't provide any interface for accessing the system by
    > providing the hash directly.


    Correct.

    > If the hacker submits the hash as though it
    > were the password, the application will hash the hash, and the computed
    > rehash won't match the stored hash. The application has to see the
    > password itself before it will grant access.


    Thats correct, but this is the typical system as it is now. How does it
    apply to the mentioned solution here?

    Alexander
    Alexander Mueller, Jan 9, 2008
    #13
  14. Alexander Mueller wrote:
    > Harlan Messinger wrote:
    >>
    >> OK, so the password has been left out of the server side entirely.
    >> Instead, to access the application you need the hash value, and the
    >> server administrator has access to *that*. So just substitute the word
    >> "password" for the word "hash" and the server administrator is now
    >> able to intercept the value of the hash that will give him access to
    >> the application.

    >
    > Correct, but the Administrator always has access to the application
    > under any user account, if he wants. The point is, he does not have
    > access to the actual password (nor does anyone using a sniffer).


    But since the hash, not the password, is what gets access to the
    application, how is this helpful? Having the value of a string called a
    "password" is not an end in itself. The point is that the administrator
    has the data he needs to get into the application. And if you're talking
    about a situation where the administrator has access to the application
    itself (this isn't a given, but you've just added it to the scenario),
    then why does it matter at all whether the administrator can see the
    password or the hash or anything else?

    >> The point of an application storing a hash instead of the original
    >> password is that it only accepts the password for authentication,
    >> computing its hash when the it's provided and comparing it with the
    >> hash it has in its user lookup table.

    >
    > Sorry, but thats not exactly the point. For the application it wouldnt
    > matter if it has to compare the hash of a given password with a stored
    > hash or simply the given plain text password with a stored plain text
    > password.
    >
    > The point is to add security against attackers - as you mentioned


    You mentioned addressing this with SSL. Your rationale for your approach
    was to shield the password from the administrator as well.

    > - as
    > well as, partly, against the Administrator, so that he cannot simply
    > reveal the user password, which is currently possible however.


    OK, this is the first time you've mentioned the issue of the
    administrator giving it to someone *else* instead of just knowing it
    himself.

    >
    >> If someone hacks the user table and finds the hashes, it won't do the
    >> hacker any good because the application doesn't provide any interface
    >> for accessing the system by providing the hash directly.

    >
    > Correct.
    >
    >> If the hacker submits the hash as though it were the password, the
    >> application will hash the hash, and the computed rehash won't match
    >> the stored hash. The application has to see the
    >> password itself before it will grant access.

    >
    > Thats correct, but this is the typical system as it is now. How does it
    > apply to the mentioned solution here?


    It applies by virtue of the fact that you haven't put the administrator
    at any kind of disadvantage in terms of gaining access to the
    application, which is what you had been claiming was the advantage of
    your approach. You finally added the missing piece, above, a case where
    your approach *does* provide additional protection.
    Harlan Messinger, Jan 9, 2008
    #14
  15. On Jan 10, 4:23 am, Alexander Mueller <> wrote:
    > Hi,
    >
    > the reason behind my email is the proposal of a new Input type named "hash"
    >
    > <input type="hash" />
    >


    <...>

    > Please let me know any comments or suggestions you have.
    >
    > Thank you,
    > Alexander Mueller


    A few years ago we had implemented a similar concept using javascript
    and hashing of the password pre posting.

    As others have mentioned, it did not prevent hackers from obtaining
    the hashed value, which of course was the same value as to be
    retrieved on the server.

    Perhaps naivety led us to feel that if the hacker did not know exactly
    what was entered into the form (pre hash), then this was at least some
    form of security.

    I think it is a great idea that you have, and I do hope that it will
    be at least investigated to the nth.
    Disco Octopus, Jan 9, 2008
    #15
  16. Harlan Messinger wrote:
    >
    > But since the hash, not the password, is what gets access to the
    > application, how is this helpful?


    Please! Reread my initial posting, all your questions should be answered
    there. All advantages are listed there.

    > Having the value of a string called a
    > "password" is not an end in itself. The point is that the administrator
    > has the data he needs to get into the application.


    Its not about getting into an application. This is always possible. Its
    about protecting the password and preventing replay attacks.

    > And if you're talking
    > about a situation where the administrator has access to the application
    > itself (this isn't a given, but you've just added it to the scenario),


    It isnt a given? In most cases the Administrator has access to the
    application itself. Whether he is allowed to access it directly is
    another issue.

    > then why does it matter at all whether the administrator can see the
    > password or the hash or anything else?


    Password and Replay protection.

    >
    > You mentioned addressing this with SSL. Your rationale for your approach
    > was to shield the password from the administrator as well.


    In terms of SSL, yes. But for HTTP it would also provide additional
    security layers.

    >
    > OK, this is the first time you've mentioned the issue of the
    > administrator giving it to someone *else* instead of just knowing it
    > himself.


    Not only necessarily to someone else, but also abusing it for other
    accounts of the user.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #16
  17. Unfortunately Disco Octopus' posting isnt listed on my newsserver, so I
    have to reply to myself .....

    Disco Octopus wrote:
    >
    > A few years ago we had implemented a similar concept using javascript
    > and hashing of the password pre posting.
    >
    > As others have mentioned, it did not prevent hackers from obtaining
    > the hashed value, which of course was the same value as to be
    > retrieved on the server.
    >
    > Perhaps naivety led us to feel that if the hacker did not know exactly
    > what was entered into the form (pre hash), then this was at least some
    > form of security.


    Of course, attackers can obtain the hashed value, but this is a simple
    replay attack and not the primary target of the hashing idea itself.
    Here the replay salt comes into play.

    >
    > I think it is a great idea that you have, and I do hope that it will
    > be at least investigated to the nth.


    Thank you, if you use Firefox 2 please have a look at the mentioned
    extension to see the actual concept.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #17
  18. Alexander Mueller wrote:
    > Harlan Messinger wrote:
    >>
    >> But since the hash, not the password, is what gets access to the
    >> application, how is this helpful?

    >
    > Please! Reread my initial posting, all your questions should be answered
    > there. All advantages are listed there.
    >
    >> Having the value of a string called a "password" is not an end in
    >> itself. The point is that the administrator has the data he needs to
    >> get into the application.

    >
    > Its not about getting into an application. This is always possible. Its
    > about protecting the password and preventing replay attacks.
    >
    >> And if you're talking about a situation where the administrator has
    >> access to the application itself (this isn't a given, but you've just
    >> added it to the scenario),

    >
    > It isnt a given? In most cases the Administrator has access to the
    > application itself.


    I mean "access" in the way we're using it to apply to anyone
    else--access to *use* the application.
    Harlan Messinger, Jan 9, 2008
    #18
  19. Disco Octopus wrote:
    >
    > A few years ago we had implemented a similar concept using javascript
    > and hashing of the password pre posting.
    >
    > As others have mentioned, it did not prevent hackers from obtaining
    > the hashed value, which of course was the same value as to be
    > retrieved on the server.
    >
    > Perhaps naivety led us to feel that if the hacker did not know exactly
    > what was entered into the form (pre hash), then this was at least some
    > form of security.


    Of course, attackers can obtain the hashed value, but this is a simple
    replay attack and not the primary target of the hashing idea itself.
    Here the replay salt comes into play.

    >
    > I think it is a great idea that you have, and I do hope that it will
    > be at least investigated to the nth.


    Thank you, if you use Firefox 2 please have a look at the mentioned
    extension to see the actual concept.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #19
  20. Harlan Messinger wrote:
    >
    > I mean "access" in the way we're using it to apply to anyone
    > else--access to *use* the application.


    Okay, but then we are in a completely different area. Administrative
    access is always more than just user access.

    Alexander
    Alexander Mueller, Jan 9, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gangesmaster

    proposal: disambiguating type

    gangesmaster, May 21, 2006, in forum: Python
    Replies:
    1
    Views:
    248
    Heiko Wundram
    May 21, 2006
  2. Victor Bazarov
    Replies:
    6
    Views:
    332
    Bo Persson
    Aug 18, 2011
  3. Dr John Stockton
    Replies:
    0
    Views:
    78
    Dr John Stockton
    Sep 12, 2003
  4. Ron Brennan
    Replies:
    5
    Views:
    312
    Dr John Stockton
    May 14, 2004
  5. Tarkeshwar
    Replies:
    2
    Views:
    187
Loading...

Share This Page