217
edits
Difference between revisions of "XMPP IM Client Design Guidelines"
Jump to navigation
Jump to search
m
XMPP IM Client Design Guidelines (view source)
Revision as of 01:53, 9 March 2021
, 01:53, 9 March 2021no edit summary
m (→Description: typo) |
Neustradamus (talk | contribs) m |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 9: | Line 9: | ||
=== Description === | === Description === | ||
XMPP Clients should only ask the user for | 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 | 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 | 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 | == 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 | 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. | ||
PLAIN is a widely used fallback that is still useful for servers that store their passwords hashed differently than required by SCRAM. | |||
See [[ | 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] | |||