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
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
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 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
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
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
> 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
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
>
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.
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
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
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
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"
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,
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
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
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
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
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
19 matches
Mail list logo
