Re: [Standards] SCRAM interoperability
But thats really little gain, with basically everyone knowing how bad it is to use the same password on different services, and it feels like it would not really be something the client dev could be blamed for. Am Do., 24. Jan. 2019 um 19:33 Uhr schrieb Jonas Schäfer < jo...@wielicki.name>: > On Donnerstag, 24. Januar 2019 19:07:09 CET Philipp Hörist wrote: > > Hm yes you are right, never thought that through as it seems. > > > > But does it really help not saving the pass on the client, what do i save > > instead? the challenge i send? if this is aquired by an attacker he can > > still access my account. > > But not any other account where you used the same password, as the salt is > (hopefully) unique. > > kind regards, > Jonas___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Donnerstag, 24. Januar 2019 19:07:09 CET Philipp Hörist wrote: > Hm yes you are right, never thought that through as it seems. > > But does it really help not saving the pass on the client, what do i save > instead? the challenge i send? if this is aquired by an attacker he can > still access my account. But not any other account where you used the same password, as the salt is (hopefully) unique. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
Hm yes you are right, never thought that through as it seems. But does it really help not saving the pass on the client, what do i save instead? the challenge i send? if this is aquired by an attacker he can still access my account. regards Am Do., 24. Jan. 2019 um 16:01 Uhr schrieb Sam Whited : > On Thu, Jan 24, 2019, at 15:55, Philipp Hörist wrote: > > SCRAM is not a mechanism to hide the password from the server > > operator. Its a mechanism to make it possible for the server operator > > to NOT store the password after getting it. > > This is also easily accomplished with PLAIN. PLAIN also makes upgrading > the password storage mechanism much more agile so it's probably safer > for most use cases. > > That being said, it does require that you store the password on the > client (unless you want the user to enter it every time), so I see that > as the primary benefit of using SCRAM, not stopping the server operator > from having to store it. > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:46 PM, Jonas Schäfer wrote: For stuff like TURN/STUN/... I would suggest to investigate the possibility of tokens for user authentication (which cannot be used to log into the XMPP service). I think I’ve seen such an implementation of a STUN/TURN/XMPP setup in the past, but I can’t remember where. I'm actually coming to conclusion that using SASL EXTERNAL is a better approach to address all those issues with SCRAM: 1) You don't keep user credentials on the server 2) A user is absolutely sure the server doesn't store the credentials 3) I'm not aware of any interop problems, well, maybe with elliptic certs, but this is resolved by server upgrades (while supporting new SHA cannot be resolved by a server upgrade only) 4) Any external service supporting TLS (such as TURN or SIP) is able to authenticate you The drawback is that client implementing this typically has terrible UX, but this can be resolved IMHO (unlike SCRAM). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019, at 15:55, Philipp Hörist wrote: > SCRAM is not a mechanism to hide the password from the server > operator. Its a mechanism to make it possible for the server operator > to NOT store the password after getting it. This is also easily accomplished with PLAIN. PLAIN also makes upgrading the password storage mechanism much more agile so it's probably safer for most use cases. That being said, it does require that you store the password on the client (unless you want the user to enter it every time), so I see that as the primary benefit of using SCRAM, not stopping the server operator from having to store it. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
SCRAM is not a mechanism to hide the password from the server operator. Its a mechanism to make it possible for the server operator to NOT store the password after getting it. Regards Philipp Am Do., 24. Jan. 2019 um 16:51 Uhr schrieb Evgeny : > On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus > wrote: > > I am not sure if the XSF is the right venue > > Well, some people cite RFC 6120, as I understand, section 13.8.1, > which requires, among others, to support SCRAM-SHA1-PLUS. So > XSF responsibility cannot be completely ruled out. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
> For stuff like TURN/STUN/... I would suggest to investigate the > possibility of > tokens for user authentication (which cannot be used to log into the XMPP > service). I think I’ve seen such an implementation of a STUN/TURN/XMPP > setup > in the past, but I can’t remember where. > We're actually implemented user auth via tokens in XMPP. It's a bit clumsy because when a client connects with password we handle him a token and break session, expecting a client to connect with token for normal session, and client can list and revoke token to terminate a session he want's to end. Storing passwords in clients is really bad idea. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019, at 15:51, Evgeny wrote: > On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus > wrote: > > I am not sure if the XSF is the right venue > > Well, some people cite RFC 6120, as I understand, section 13.8.1, > which requires, among others, to support SCRAM-SHA1-PLUS. So XSF > responsibility cannot be completely ruled out. That document is the purview of the IETF, not the XSF (that being said, I agree with you, this is as good a place to start working on it as any). I've had a document that I've been meaning to publish for a while that details how clients can do auth mechanism pinning to prevent downgrade attacks; it might also be a good place to discuss this, but I could see a separate document outlining best practices being useful as well (or just a wiki page). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:39 PM, Florian Schmaus wrote: I am not sure if the XSF is the right venue Well, some people cite RFC 6120, as I understand, section 13.8.1, which requires, among others, to support SCRAM-SHA1-PLUS. So XSF responsibility cannot be completely ruled out. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Donnerstag, 24. Januar 2019 16:20:57 CET Evgeny wrote: > On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus > > wrote: > > Then you can't authenticate unless the server also stores the > > authentication data for SCRAM-SHA1. I guess that is your point. What > > is > > wrong with the server storing the required data to authenticate > > clients > > with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation > > overhead > > argument)? Maybe I am missing something? > > I am not sure what you mean. I can only do that on the server > if I get plain password from the client which is something SCRAM > was designed to prevent if I understand it correctly. You see the plaintext password during registration. That’s when you create the SCRAM blobs on the server side. > Also, the problem still remains with upgrading existing > SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there > is possibility to create interop problem again, unless a client > 1) supports all previous SHA versions > 2) doesn't treat previous SHA versions as a downgrade attack Upgrading SCRAM is a Pain In The you-know-what, as you correctly identified yourself. The interoperability with other services isn’t great either, as you also identified. For stuff like TURN/STUN/... I would suggest to investigate the possibility of tokens for user authentication (which cannot be used to log into the XMPP service). I think I’ve seen such an implementation of a STUN/TURN/XMPP setup in the past, but I can’t remember where. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:37 PM, Philipp Hörist wrote: You get the password in plain at the point when the user creates the account. Then you save it in 1 and 256. In this case what prevents an operator to store plain password as well? And we force him to do so, when he also runs STUN/TURN/SIP service with the same credentials (the problem which is totally ignored). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On 24.01.19 16:20, Evgeny wrote: > On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus wrote: >> Then you can't authenticate unless the server also stores the >> authentication data for SCRAM-SHA1. I guess that is your point. What is >> wrong with the server storing the required data to authenticate clients >> with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation overhead >> argument)? Maybe I am missing something? > > I am not sure what you mean. I can only do that on the server > if I get plain password from the client which is something SCRAM > was designed to prevent if I understand it correctly. I don't think that SCRAM was designed to prevent handing over the plaintext password *on account creation*. Although reducing the exposure of the plaintext password is always a good idea. That is why modern challenge response authentication mechanism do not require the server to *store* the password in plaintext. That was/is one design goal of SCRAM. Happy to stand corrected. > Also, the problem still remains with upgrading existing > SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there > is possibility to create interop problem again, unless a client > 1) supports all previous SHA versions > 2) doesn't treat previous SHA versions as a downgrade attack I agree that a few words about future interoperability would be nice. Although I think that there is possibly not much to say about it, besides that servers are encouraged to support both mechanisms for a certain time period. I am not sure if the XSF is the right venue, since it is an IETF standard and other protocols using SASL should also be affected. May I suggest to ask for opinions on this on the kitten WG [1] mailing list? - Florian 1: https://datatracker.ietf.org/wg/kitten/about/ signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited wrote: Depending on the TLS library you use, it may also not give you the TLS first message unless you're not doing renegotiation, in which case you're also safe. There is another problem with TLS offload, because to my knowledge "proxy protocol" (supported by haproxy and others) doesn't support forwarding of TLS handshake messages (or tls-unique along) to the backend (i.e. XMPP server). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
Hi, You get the password in plain at the point when the user creates the account. Then you save it in 1 and 256. If your question is that this is not possible anymore for people that created their account when you only offered SHA1. Yes there is no way around it, you cant migrate these users, they have to reset the password. I guess you think about only using 256 for new users, old users fail, try another mechanism and succeed. This is tricky i guess. There is nothing mentioned on how many times a client should try another mechanism or if it should at all. Scram makes it possible that a client can, but for example Gajim will not try another mechanism right now, but only because i didnt saw a reason how this could be a benefit other than hiding server implementation errors. If i were a server dev, i would probably chose to only use 256 in completely new setups, or if the operator is willing to reset all passwords. Especially in the light that its not clear if SHA256 is really a worthy gain over SHA1 in the context of SCRAM. regards Philipp 2019-01-24 16:20 GMT+01:00, Evgeny : > On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus > wrote: >> Then you can't authenticate unless the server also stores the >> authentication data for SCRAM-SHA1. I guess that is your point. What >> is >> wrong with the server storing the required data to authenticate >> clients >> with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation >> overhead >> argument)? Maybe I am missing something? > > I am not sure what you mean. I can only do that on the server > if I get plain password from the client which is something SCRAM > was designed to prevent if I understand it correctly. > Also, the problem still remains with upgrading existing > SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there > is possibility to create interop problem again, unless a client > 1) supports all previous SHA versions > 2) doesn't treat previous SHA versions as a downgrade attack > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:05 PM, Sam Whited wrote: To my knowledge, we don't have a good solution for this. Okay. In this situation the only solution for me is not implementing anything except SHA1 to avoid interop problems. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019 at 6:11 PM, Florian Schmaus wrote: Then you can't authenticate unless the server also stores the authentication data for SCRAM-SHA1. I guess that is your point. What is wrong with the server storing the required data to authenticate clients with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation overhead argument)? Maybe I am missing something? I am not sure what you mean. I can only do that on the server if I get plain password from the client which is something SCRAM was designed to prevent if I understand it correctly. Also, the problem still remains with upgrading existing SHA-1 to SHA-256/384/512/whatever and if I don't upgrade it there is possibility to create interop problem again, unless a client 1) supports all previous SHA versions 2) doesn't treat previous SHA versions as a downgrade attack ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On 24.01.19 15:38, Evgeny wrote: > Hi there. > > Can someone please clarify how to maintain ineroperablity of > SCRAM-SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g. > when some clients support SCRAM-SHA1 only, but the password > was created in SCRAM-SHA256 format. Then you can't authenticate unless the server also stores the authentication data for SCRAM-SHA1. I guess that is your point. What is wrong with the server storing the required data to authenticate clients with eg. SCRAM-SHA1 or SCRAM-SHA256 (besides the implementation overhead argument)? Maybe I am missing something? >> After publication of [RFC5802], it was discovered that Transport >> Layer Security (TLS) [RFC5246] does not have the expected properties >> for the "tls-unique" channel binding to be secure [RFC7627] > > Does that mean that "-PLUS" doesn't provide additional security > and is now useless? No, only when tls-unique is used and if RFC 7627 is *not* used. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] SCRAM interoperability
On Thu, Jan 24, 2019, at 14:40, Evgeny wrote: > Can someone please clarify how to maintain ineroperablity of SCRAM- > SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g. when some clients > support SCRAM-SHA1 only, but the password was created in SCRAM-SHA256 > format. I know it's still possible to authenticate via PLAIN, however: To my knowledge, we don't have a good solution for this. This is the problem with proof-of-posession based mechanisms like SCRAM: if you never know the password after the first time it's set, it's hard to be agile with your mechanisms without requiring a password reset. Arguably, this makes them not a good idea because being able to rotate the password storage mechanism quickly in case a vulnerability is discovered in the current mechanism is a nice property to have, whereas the server not knowing the password is less valueable unless you are forced to use a server that you're worried might become malicious in the future (which is probably unlikely). > Another problem is with "-PLUS" formats. RFC 7677 states: > > > After publication of [RFC5802], it was discovered that Transport > > Layer Security (TLS) [RFC5246] does not have the expected > > properties for the "tls-unique" channel binding to be secure > > [RFC7627] > > Does that mean that "-PLUS" doesn't provide additional security and is > now useless? This is true during resumption, so you can use -PLUS as long as you're not resuming an existing TLS session. For more info see: https://mitls.org/pages/attacks/3SHAKE#channelbindings Once the extended master secret fix has been widely adopted (I'm not sure what the current status of this is) this will stop being a problem. Depending on the TLS library you use, it may also not give you the TLS first message unless you're not doing renegotiation, in which case you're also safe. > I'd like to see XSF taking a clear position on this as well as > creating some recommendation for the implementors because the > disambiguation creates interoperability problems. This is a good idea. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] SCRAM interoperability
Hi there. Can someone please clarify how to maintain ineroperablity of SCRAM-SHA1 vs SCRAM-SHA256 vs SCRAM-SHA-WHATEVER, e.g. when some clients support SCRAM-SHA1 only, but the password was created in SCRAM-SHA256 format. I know it's still possible to authenticate via PLAIN, however: 1) Using PLAIN creates a potential DoS for the server due to expensive HMAC computational rounds. 2) Some admins prefer to disable PLAIN completely. 3) A client may see PLAIN as a downgrade attack. This can happen when the password was changed from another client with an incompatible SCRAM version. Another problem is with "-PLUS" formats. RFC 7677 states: > After publication of [RFC5802], it was discovered that Transport > Layer Security (TLS) [RFC5246] does not have the expected properties > for the "tls-unique" channel binding to be secure [RFC7627] Does that mean that "-PLUS" doesn't provide additional security and is now useless? And yet another problem is that SCRAM is unusable with third-party services such as STUN/TURN or SIP which support only DIGEST HTTP-like authentication and thus preventing from sharing the same credentials between the services. I'd like to see XSF taking a clear position on this as well as creating some recommendation for the implementors because the disambiguation creates interoperability problems. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
