Difference between revisions of "XMPP IM Client Design Guidelines"

Jump to navigation Jump to search
m
no edit summary
m
 
(7 intermediate revisions by 2 users not shown)
Line 9: Line 9:
=== Description ===
=== Description ===


XMPP Clients should only ask the user for his JID and password. A proper XMPP setup does not require more information in order for the client to establish a successful connection to the server. There should be a single JID text field in which the user is expected to enter his bare JID. Visual feedback once it was detected that a valid bare JID was entered, e.g. a green check mark or changing the field's background color (from red) to green, is also a good idea.
XMPP Clients should only ask the user for their JID and password. A proper XMPP setup does not require more information in order for the client to establish a successful connection to the server. There should be a single JID text field in which the user is expected to enter their bare JID. Visual feedback once it was detected that a valid bare JID was entered, e.g. a green check mark or changing the field's background color (from red) to green, is also a good idea.


=== Rationale ===
=== Rationale ===


Splitting the JID into multiple input fields makes it impossible for the user to simply copy&paste his JID into the field. Asking the user for more then his bare JID and password increases the UI elements and reduces the usability.
Splitting the JID into multiple input fields makes it impossible for the user to simply copy&paste their JID into the field. Asking the user for more then their bare JID and password increases the UI elements and reduces the usability.


== Provide an advanced option allowing the user to specify the host and port to connect to ==
== Provide an advanced option allowing the user to specify the host and port to connect to ==
Line 65: Line 65:
=== Description ===
=== Description ===


Users want to know the type of a remote resource, e.g. "Is this the resource of my friends mobile device or of his desktop?". Clients should display the type using the 'identity' information provided by [http://xmpp.org/extensions/xep-0030.html#info-basic XEP-30 disco#info] query results. Also they should set a meaningful XEP-30 'identity'. So instead of having a resource like '/work-pc', the client should return
Users want to know the type of a remote resource, e.g. "Is this the resource of my friends mobile device or of their desktop?". Clients should display the type using the 'identity' information provided by [http://xmpp.org/extensions/xep-0030.html#info-basic XEP-30 disco#info] query results. Also they should set a meaningful XEP-30 'identity'. So instead of having a resource like '/work-pc', the client should return


<pre name='xml'>
<pre name='xml'>
Line 118: Line 118:




== Implement SCRAM-SHA-1 ==
== Implement PLAIN and SCRAM ==


=== Description ===
=== Description ===
Line 124: Line 124:
Do '''not''': Implement DIGEST-MD5 or CRAM-MD5. These mechanisms only work if the server has access to the plain password.
Do '''not''': Implement DIGEST-MD5 or CRAM-MD5. These mechanisms only work if the server has access to the plain password.


Do: Implement SCRAM-SHA-1 and PLAIN.
Do: Implement SCRAM-SHA-1 / SCRAM-SHA-256 / SCRAM-SHA-512 / SCRAM-SHA3-512 and PLAIN.


=== Rationale ===
=== Rationale ===


Hashing and salting passwords helps making it hard to retrieve the plain password from a compromised server. However, we would also like to be able to protect the password while it is in transit. These two concepts are difficult to combine: DIGEST-MD5 and CRAM-MD5 only protect the password in transit – the mechanisms can't work if the server wants to store the password hashed and salted. SCRAM-SHA-1 fixes that and supports both hashed storage and hashed transmission.
Hashing and salting passwords helps making it hard to retrieve the plain password from a compromised server. However, we would also like to be able to protect the password while it is in transit. These two concepts are difficult to combine: DIGEST-MD5 and CRAM-MD5 do not protect the password in transit or at rest – the mechanisms can't work if the server wants to store the password hashed and salted. SCRAM protects the password both in flight and at rest.


While it would be nice to deprecate PLAIN, it is still needed for servers who use a different hashing mechanism than SCRAM-SHA-1 needs.
PLAIN is a widely used fallback that is still useful for servers that store their passwords hashed differently than required by SCRAM.


See [[SASLandSCRAM-SHA-1]] for help with implementing SCRAM-SHA-1.
See [[SASL Authentication and SCRAM]] for help with implementing SCRAM.
 
For more detailed and up to date recommendations see [https://xmpp.org/extensions/xep-0438.html XEP-0438: Best practices for password hashing and storage]
217

edits

Navigation menu