Is there such a thing as "Password Safe Forwarding"?

Tue Jun 19 19:46:36 AEST 2018

On 06/19/2018 02:36 AM, Stephen Harris wrote:
> On Tue, Jun 19, 2018 at 02:13:56AM +0200, Jochen Bern wrote:
>> Enter a corporate password policy that requires passwords to be complex,
>> different everywhere, and of limited lifetime. It helpfully suggests the
>> use of password safes, but doesn't allow the lifetime to be extended by
>> making the password *really* complex.
> 
> A sufficiently advanced password vault (e.g. CyberArk EPV) will allow a
> user to request the current password and then will reset the password
> some time later (eg 24 hours)... and can ensure passwords are reset
> every 80 days (or whatever) so they don't expire.  There's a number
> of products on the market that can do this.  In the worst case they
> ssh into the account with the old password, run the "passwd" command
> and set a new one.  In a good case they have access to a privileged
> account (eg one with "sudo passwd") so they can reset the password
> even if the old one doesn't work.

Hmmmm, noted. I'm afraid that as-is, said company policy is not willing
to give the nod to a *central* password storage, much less one that
actively *uses* them (to change them in time) ...

(It *also* fails to even mention tokens, OTPs, biometry, 2FA as a whole,
etc.. As I said, it was written "upstairs". Password safes for those who
would otherwise need to memorize dozens of passwords appear in a single
sentence tacked onto the end of a paragraph, clearly an afterthought ...)

>> Hence my question: Are there ideas/plans/projects to have an OpenSSH
>> connection provide a communication channel between password safe(*) and
>> the remote password-changing mechanisms, similar to how Authentication
>> Agent Forwarding mediates communication between a local ssh-agent and
>> remote ssh/scp/sftp/... clients? Would there be suitable pre-existing
>> protocols to communicate stuff like "password change needed yes/no",
>> "new password failed, please retry" etc. etc. between the end points?
> 
> If you go down this route then it sounds like a a PAM password change
> module that can push the new password into the vault might be a better
> option, so if the "passwd" command is run then it'll also push it.
> 
> I don't think sshd is the right place for this.

The scenario is that the user has a password safe at hand (whether it is
actually *running* locally or not), PAM at remote decides that the password
@remote needs to be changed, and ssh at local and sshd at remote have *just*
established and fully authenticated a connection between the two hosts.

(Add to that that "local" is a workplace in a fully SNATed LAN, "remote"
includes customer premises installations somewhere over the Internet,
some even requiring use of a remote jump host, and I do *not* want to
Just Trust(tm) PAM at remote not to finger whichever entry it pleases if I
were to give it a separate, transparent, agnostic connection to the
password safe.)

I'm sort of seeing the ssh client as the component that can authenticate
(PAM@)remote to the password safe and authorize access to the *one*
correct entry, because it *already has* most of the information&channels
needed to do that.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Fon:    +49 6151 9067-231
Fax:    +49 6151 9067-290
E-Mail: jochen.bern at binect.de

www.binect.de
www.facebook.de/binect

Binect ist ausgezeichnet:
Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017

Binect GmbH

Robert-Koch-Straße 9, 64331 Weiterstadt, DE

Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold
Unternehmenssitz: Weiterstadt
Register:         Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
✁
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180619/64e6c251/attachment.p7s>