On 30.04.20 01:15, Bernd Zeimetz wrote:
>
> On 4/28/20 3:20 PM, Thomas Goirand wrote:
>
>> That's not the case. An MITM attack could gain a session and maintain it
>> open, while the end user would just notice "oh shit, I miss-typed the
>> 2FA numbers, let's try again". Then the only thing the
On 4/28/20 3:20 PM, Thomas Goirand wrote:
> That's not the case. An MITM attack could gain a session and maintain it
> open, while the end user would just notice "oh shit, I miss-typed the
> 2FA numbers, let's try again". Then the only thing the attacker needs to
> do is keep the session open
On 2020-04-28 18:48, Jeremy Stanley wrote:
On 2020-04-28 14:32:55 +0200 (+0200), Bernd Zeimetz wrote:
On 2020-04-28 14:27, PICCA Frederic-Emmanuel wrote:
> Is it possible to use it's ssh key in order to have acces to
> the salsa api ? I mean instead of the token, which looks to me
> quite
On 2020-04-28 14:32:55 +0200 (+0200), Bernd Zeimetz wrote:
> On 2020-04-28 14:27, PICCA Frederic-Emmanuel wrote:
> > Is it possible to use it's ssh key in order to have acces to
> > the salsa api ? I mean instead of the token, which looks to me
> > quite fragile compare to ssh via a gpg card and
On Tue, Apr 28, 2020 at 02:32:55PM +0200, Bernd Zeimetz wrote:
> If you use ssh, you can create an own account for the ssh key and give
> it very special permissions, if you need it for automatic pushes or
> similar things.
Or add it as writable deploy key to a project.
Bastian
--
I'm a
On 4/28/20 2:30 PM, Bernd Zeimetz wrote:
>
>
> On 4/27/20 2:49 AM, Paride Legovini wrote:
>> An active MITM attack is way more complicated than just sniffing and
>> storing traffic for later analysis. Changing the 2FA or password is not
>> a great strategy, as you would immediately realize
On 2020-04-28 14:27, PICCA Frederic-Emmanuel wrote:
Is it possible to use it's ssh key in order to have acces to the salsa
api ?
I mean instead of the token, which looks to me quite fragile compare
to ssh via a gpg card and the gpg agent.
The api works with a token - and without 2fa. That
On 4/27/20 2:49 AM, Paride Legovini wrote:
> An active MITM attack is way more complicated than just sniffing and
> storing traffic for later analysis. Changing the 2FA or password is not
> a great strategy, as you would immediately realize what's going on.
> Silently gaining access to an
On 4/26/20 10:29 PM, Jeremy Stanley wrote:
> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to
On 2020-04-28 05:08, Wookey wrote:
On 2020-04-26 14:07 +0200, Bernd Zeimetz wrote:
Hi,
Google Authenticator is a software-based authenticator by Google that
implements two-step verification services using the Time-based
One-time
Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based
On Monday, 27 April 2020 17:11:21 PDT Jeremy Stanley wrote:
> On 2020-04-27 16:28:39 -0700 (-0700), Ihor Antonov wrote:
> > On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:
> >
> > The subject of this thread was click-baity enough but this thread appears
> > to be a wonderful
On 2020-04-26 14:07 +0200, Bernd Zeimetz wrote:
> Hi,
>
> Google Authenticator is a software-based authenticator by Google that
> implements two-step verification services using the Time-based One-time
> Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time
> Password algorithm
On 2020-04-27 16:28:39 -0700 (-0700), Ihor Antonov wrote:
> On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:
>
> The subject of this thread was click-baity enough but this thread appears to
> be a wonderful bike-shedding with MFA flavor.
>
> Please help me find the original thread, as
On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:
The subject of this thread was click-baity enough but this thread appears to
be a wonderful bike-shedding with MFA flavor.
Please help me find the original thread, as my Salsa account is still "-guest"
and I want no more of it.
Thanks
Russ Allbery schrieb:
> Vincent Bernat writes:
>
>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to
On 4/27/20 7:34 PM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> Except that SQRL has no password involved, just crypto.
>
>> Since you are too lazy to read on, let me do a tl;dr. Simply put, the
>> client holds a private key. From that private key, a new one is derived
>> doing a HMAC of
Thomas Goirand writes:
> Except that SQRL has no password involved, just crypto.
> Since you are too lazy to read on, let me do a tl;dr. Simply put, the
> client holds a private key. From that private key, a new one is derived
> doing a HMAC of that key with the domain, meaning a client has a
On 4/27/20 2:19 AM, Russ Allbery wrote:
> Thomas Goirand writes:
>
>> Now, if you want something safer, maybe we could implement something
>> that involves crypto a smarter way, like SQRL, so we avoid storing any
>> password in Salsa, even hashed:
>> https://www.grc.com/sqrl/sqrl.htm
>
> I
❦ 26 avril 2020 15:04 -07, Russ Allbery:
>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org,
Thomas Goirand wrote on 27/04/2020:
> On 4/27/20 12:18 AM, Paride Legovini wrote:
>> It's still one static shared secret you need to enter every time. If it
>> gets stolen, because your browser or your computer is compromised, or in
>> a MITM attack where the attacker gained access to a valid
Russ Allbery writes:
> That's effectively what a password manager simulates, albeit trading off
> local secure storage for convenience while limiting the strong passwords
> someone has to memorize to one. I would argue that the only functional
> difference between a properly-configured password
Thomas Goirand writes:
> Now, if you want something safer, maybe we could implement something
> that involves crypto a smarter way, like SQRL, so we avoid storing any
> password in Salsa, even hashed:
> https://www.grc.com/sqrl/sqrl.htm
I don't know anything about SQRL (and am too lazy to try
On 4/27/20 12:18 AM, Paride Legovini wrote:
> It's still one static shared secret you need to enter every time. If it
> gets stolen, because your browser or your computer is compromised, or in
> a MITM attack where the attacker gained access to a valid certificate
> for salsa.debian.org [1,2],
On 4/26/20 8:34 PM, Bernd Zeimetz wrote:
>
>
> On 4/26/20 12:41 AM, Thomas Goirand wrote:
>> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>>> Actually I think 2FA should be enforced for everybody.
>>> Even debian.org related passwords might get lost.
>>
>> I use strong password, stored with
Paride Legovini writes:
> It's still one static shared secret you need to enter every time. If it
> gets stolen, because your browser or your computer is compromised, or in
> a MITM attack where the attacker gained access to a valid certificate
> for salsa.debian.org [1,2], your account is gone.
Thomas Goirand wrote on 26/04/2020:
> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
>> Even debian.org related passwords might get lost.
>
> I use strong password, stored with keepassxc, with the password db
> encrypted using the HMAC of my
Hello,
On Sun 26 Apr 2020 at 10:53PM +02, Vincent Bernat wrote:
> ❦ 26 avril 2020 20:29 +00, Jeremy Stanley:
>
>> You're already seeing quite a few folks responding that being
>> required to use an additional application or device each time they
>> authenticate would be an inconvenience to
Am 26.04.2020 um 23:47 schrieb Paride Legovini:
>
> Another good one with builtin backup functionality is Aegis [1,2]. It's
> GPLv3 and available via f-droid.
>
Thanks, haven't heard of it before but looks interesting.
Michael
--
Why is it that all of the instruments seeking intelligent life
Vincent Bernat writes:
> This is not how this is implemented. I am using GitHub and GitLab with
> 2FA enabled and I am rarely asked to enter any token. Once you get
> authenticated on a device, it remains for a long time.
Pretty much every time I go to salsa.debian.org, I have to log back in
Mattia Rizzolo writes:
> Since I sometimes I don't really know my passwords, I suppose at that
> point the "something I know" instead of being the actual password is the
> GPG passphrase used to decrypt the file that actually contains the
> password, but it's still 2fa.
By equivalent logic, a
Michael Biebl wrote on 26/04/2020:
> Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
>> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>>> There are even cli tools that do the same stuff. I'd guess there is at
>>> least one on Debian.
>>
>> Indeed, after I first lost a phone, and a
❦ 26 avril 2020 20:29 +00, Jeremy Stanley:
> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to
On 2020-04-26 21:02:34 +0200 (+0200), Bernd Zeimetz wrote:
> On 4/26/20 8:30 PM, Bastian Blank wrote:
> > On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> >> Actually I think 2FA should be enforced for everybody.
> >
> > No, we don't enforce 2FA for everybody. And I don't
On 4/26/20 8:46 PM, Johannes Schauer wrote:
> Quoting Bernd Zeimetz (2020-04-26 20:34:12)
>> On 4/26/20 12:41 AM, Thomas Goirand wrote:
>>> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
Actually I think 2FA should be enforced for everybody.
Even debian.org related passwords might get
On 4/26/20 8:30 PM, Bastian Blank wrote:
> On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
>
> No, we don't enforce 2FA for everybody. And I don't consider it
> appropriate to raise the option.
Could you explain why?
On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.
No, we don't enforce 2FA for everybody. And I don't consider it
appropriate to raise the option.
However, you may choose to enforce 2FA for all users of your groups.
Regards,
Quoting Bernd Zeimetz (2020-04-26 20:34:12)
> On 4/26/20 12:41 AM, Thomas Goirand wrote:
> > On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
> >> Actually I think 2FA should be enforced for everybody.
> >> Even debian.org related passwords might get lost.
> > I use strong password, stored with
On 4/26/20 12:31 AM, Gard Spreemann wrote:
> Right, but what's the threat model here? For some of us, losing the
> Salsa password is essentially only possible if we have had our PGP
> dongle or offline private key backup compromised. In this case, the
> attacker can sign uploads to the archive
On 4/26/20 2:40 PM, Michael Biebl wrote:
> Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
>> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>>> There are even cli tools that do the same stuff. I'd guess there is at
>>> least one on Debian.
>>
>> Indeed, after I first lost a
On 4/26/20 12:41 AM, Thomas Goirand wrote:
> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
>> Even debian.org related passwords might get lost.
>
> I use strong password, stored with keepassxc, with the password db
> encrypted using the
On 4/26/20 7:12 PM, Sean Whitton wrote:
> In such a case, though, haven't you essentially turned it back into one
> factor authentication (the single factor being your laptop)?
Still better than losing a single password in whatever way in the
internet. Targeted phishing attacks for example.
Le 26/04/2020 à 14:07, Bernd Zeimetz a écrit :
> Hi,
>
> Google Authenticator is a software-based authenticator by Google that
> implements two-step verification services using the Time-based One-time
> Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time
> Password algorithm
On Sun, Apr 26, 2020 at 10:12:41AM -0700, Sean Whitton wrote:
> On Sun 26 Apr 2020 at 02:36PM +02, Mattia Rizzolo wrote:
> > On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
> >> There are even cli tools that do the same stuff. I'd guess there is at
> >> least one on Debian.
> >
Hello,
On Sun 26 Apr 2020 at 02:36PM +02, Mattia Rizzolo wrote:
> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>> There are even cli tools that do the same stuff. I'd guess there is at least
>> one on Debian.
>
> Indeed, after I first lost a phone, and a second one broke,
On Sun, Apr 26, 2020 at 12:31:42AM +0200, Gard Spreemann wrote:
>
> Bernd Zeimetz writes:
> > Actually I think 2FA should be enforced for everybody.
> > Even debian.org related passwords might get lost.
>
> Right, but what's the threat model here? For some of us, losing the
> Salsa password is
Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>> There are even cli tools that do the same stuff. I'd guess there is at least
>> one on Debian.
>
> Indeed, after I first lost a phone, and a second one broke, leaving me
> with a
❦ 26 avril 2020 14:07 +02, Bernd Zeimetz:
> There are even cli tools that do the same stuff. I'd guess there is at
> least one on Debian.
There is oathtool.
--
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"
signature.asc
Description: PGP
On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
> There are even cli tools that do the same stuff. I'd guess there is at least
> one on Debian.
Indeed, after I first lost a phone, and a second one broke, leaving me
with a quite huge pain to recover my accounts, I started using
Hi,
Google Authenticator is a software-based authenticator by Google that
implements two-step verification services using the Time-based One-time
Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time
Password algorithm (HOTP; specified in RFC 4226), for authenticating users
On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.
> Even debian.org related passwords might get lost.
I use strong password, stored with keepassxc, with the password db
encrypted using the HMAC of my yubikey. In what way is this not safe
enough
Bernd Zeimetz writes:
> On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote:
>> On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
>>> Hi,
>>>
>>> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>>>
>>> Enforce that (if Salsa is doing that in the meantime, ignore me).
>>
>>
On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote:
> On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
>> Hi,
>>
>> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>>
>> Enforce that (if Salsa is doing that in the meantime, ignore me).
>
> i hope you don't suggest to
On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
> Hi,
>
> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>
> Enforce that (if Salsa is doing that in the meantime, ignore me).
i hope you don't suggest to enforce 2FA system-wide for all users of salsa.
i read you original mail as a
Hi,
https://docs.gitlab.com/ee/security/two_factor_authentication.html
Enforce that (if Salsa is doing that in the meantime, ignore me).
Bernd
Am 25. April 2020 18:49:41 MESZ schrieb Bastian Blank :
>Hi Bernd
>
>On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
>> On 4/18/20
Hi Bernd
On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
> On 4/18/20 11:33 PM, Bastian Blank wrote:
> > You are encouraged to use Salsa as an authentication provider for Debian
> > services. GitLab supports plain OAuth2 and OpenID Connect as
> > authentiation protocols. Every
Hi Bastian,
thanks for your work!
On 4/18/20 11:33 PM, Bastian Blank wrote:
> You are encouraged to use Salsa as an authentication provider for Debian
> services. GitLab supports plain OAuth2 and OpenID Connect as
> authentiation protocols. Every user can register their own applications
> and
56 matches
Mail list logo
