Re: [pure-ftpd] TOTP for Pureftpd

Lothar Kimmeringer <[email protected]> Thu, 1 Apr 2021 11:12:32 +0200
Newsgroups gmane.network.pureftpd.user
Message-ID <[email protected]>

Am 29.03.2021 um 12:52 schrieb Mario:

> Compatibility with existing tools would be maintained by still having a single password to enter.

I'm aware that it's not preventing clients from working with this version of a server
but without an additional dialog box that allows you to enter the OTP, you can't use
the host management tools most GUI-based FTP clients provide.

> Example: suppose the user is Alice and the base password is RabbitFoot,
> then Alice would need to provide a password that is a combination of the
> base password and the TOTP password.

I already understood your explanation the first time ;-) But my argument
still stands: FTP is a standardized protocol, so if you want to add a
new feature to it, you need to follow procedures to extend it if you want
to see it added to the standard feature set of an FTP-server.

> SFTP is not so simple to set up

Concerning difficulty I beg to differ. SSH is set up much easier than FTP
concerning all the fuss with dynamic ports to be opened up in the firewall,
servers like pureftpd not adding the extended master secret extension to
their handshake forcing all Java based FTP client to globally switch off
that security feature in order to be able to communicate, etc. SSH on
the other side is a simple port to be opened.

> and it does not necessarily implement 2FA.

It comes with public key authentication that is much harder to brute force
than a password.

> Also, IMHO "2FA" does not imply that is has to be implemented in two steps,
> but you do need to have 2 factors. So combining both factors in a single
> password seems ok to me.

It might be OK if you need a WFM-solution but if you want something that
is part of a standard product, this is not a solution.

> My proposal would be supported by any existing client, but the user can
> not use any saved password anymore.

Which will lead to non-acceptance in the user base. You also prevent your
server to be usable for EDI-implementations because it would require the
peers to do programmatic changes to their FTP clients in order to authenticate
and send their orders.


Cheers, Lothar