Changeset 22


Ignore:
Timestamp:
11/09/13 16:27:45 (8 years ago)
Author:
julian.reschke@…
Message:

security considerations

Location:
draft-ietf-httpauth-basicauth-update/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.html

    r21 r22  
    254254  margin-left: 0em;
    255255}
    256 
     256.bcp14 {
     257  font-style: normal;
     258  text-transform: lowercase;
     259  font-variant: small-caps;
     260}
    257261.comment {
    258262  background-color: yellow;
     
    581585      </p>
    582586      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    583       <p id="rfc.section.4.p.1"><span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: Copy from RFC 2617 and augment.]</span>
     587      <p id="rfc.section.4.p.1">The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity,
     588         which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent the addition of enhancements
     589         (such as schemes to use one-time passwords) to Basic authentication.
     590      </p>
     591      <p id="rfc.section.4.p.2">The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password
     592         over the physical network. Many other authentication schemes address this problem.
     593      </p>
     594      <p id="rfc.section.4.p.3">Because Basic authentication involves the cleartext transmission of passwords it <em class="bcp14">SHOULD NOT</em> be used (without enhancements) to protect sensitive or valuable information.
     595      </p>
     596      <p id="rfc.section.4.p.4">A common use of Basic authentication is for identification purposes — requiring the user to provide a user name and password
     597         as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this
     598         way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major
     599         concern. This is only correct if the server issues both user name and password to the users and in particular does not allow
     600         the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid
     601         the task of maintaining multiple passwords.
     602      </p>
     603      <p id="rfc.section.4.p.5">If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the
     604         server but also unauthorized access to any other resources on other systems that the user protects with the same password.
     605         Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner
     606         or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all
     607         those sites if this information is not maintained in a secure fashion.
     608      </p>
     609      <p id="rfc.section.4.p.6">Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting
     610         to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or
     611         gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not
     612         possible with Digest Authentication. Server implementers <em class="bcp14">SHOULD</em> guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous
     613         for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism
     614         to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable
     615         by the client.
    584616      </p>
    585617      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
     
    591623      <p id="rfc.section.6.p.1">This specification takes over the definition of the "Basic" HTTP Authentication Scheme, previously defined in RFC 2617. We
    592624         thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence
    593          C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
     625         C. Stewart for their work on that specification, from which significant amounts of text was borrowed. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    594626      </p>
    595627      <h1 id="rfc.references"><a id="rfc.section.7" href="#rfc.section.7">7.</a> References
  • draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.xml

    r21 r22  
    2222  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
    2323  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
     24  <!ENTITY mdash "&#8212;">
    2425]>
    2526
     
    115116</section> 
    116117
    117 
    118118<section title="Security Considerations" anchor="security.considerations">
    119119<t>
    120   <cref>Copy from RFC 2617 and augment.</cref>
     120   The Basic authentication scheme is not a secure method of user
     121   authentication, nor does it in any way protect the entity, which is
     122   transmitted in cleartext across the physical network used as the
     123   carrier. HTTP does not prevent the addition of enhancements (such as
     124   schemes to use one-time passwords) to Basic authentication.
     125</t>
     126<t>
     127   The most serious flaw in Basic authentication is that it results in
     128   the essentially cleartext transmission of the user's password over
     129   the physical network. Many other authentication schemes address this
     130   problem.
     131</t>
     132<t>
     133   Because Basic authentication involves the cleartext transmission of
     134   passwords it &SHOULD-NOT; be used (without enhancements) to protect
     135   sensitive or valuable information.
     136</t>
     137<t>
     138   A common use of Basic authentication is for identification purposes
     139   &mdash; requiring the user to provide a user name and password as a means
     140   of identification, for example, for purposes of gathering accurate
     141   usage statistics on a server. When used in this way it is tempting to
     142   think that there is no danger in its use if illicit access to the
     143   protected documents is not a major concern. This is only correct if
     144   the server issues both user name and password to the users and in
     145   particular does not allow the user to choose his or her own password.
     146   The danger arises because naive users frequently reuse a single
     147   password to avoid the task of maintaining multiple passwords.
     148</t>
     149<t>
     150   If a server permits users to select their own passwords, then the
     151   threat is not only unauthorized access to documents on the server but
     152   also unauthorized access to any other resources on other systems that
     153   the user protects with the same password. Furthermore, in the
     154   server's password database, many of the passwords may also be users'
     155   passwords for other sites. The owner or administrator of such a
     156   system could therefore expose all users of the system to the risk of
     157   unauthorized access to all those sites if this information is not
     158   maintained in a secure fashion.
     159</t>
     160<t>
     161   Basic Authentication is also vulnerable to spoofing by counterfeit
     162   servers. If a user can be led to believe that he is connecting to a
     163   host containing information protected by Basic authentication when,
     164   in fact, he is connecting to a hostile server or gateway, then the
     165   attacker can request a password, store it for later use, and feign an
     166   error. This type of attack is not possible with Digest
     167   Authentication. Server implementers &SHOULD; guard against the
     168   possibility of this sort of counterfeiting by gateways or CGI
     169   scripts. In particular it is very dangerous for a server to simply
     170   turn over a connection to a gateway.  That gateway can then use the
     171   persistent connection mechanism to engage in multiple transactions
     172   with the client while impersonating the original server in a way that
     173   is not detectable by the client.
    121174</t>
    122175</section> 
     
    139192  Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
    140193  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on
    141   that specification. See <xref target="RFC2617" x:fmt="of" x:sec="6"/> for
    142   further acknowledgements.
     194  that specification, from which significant amounts of text was borrowed.
     195  See <xref target="RFC2617" x:fmt="of" x:sec="6"/> for further acknowledgements.
    143196</t>
    144197</section> 
Note: See TracChangeset for help on using the changeset viewer.