Using an OAuth-based workflow that incorporates 2FA. That is already possible.
What is *really* hard is to incorporate 2FA into the svn client/libraries. The most straightforward is to use bearer/PAT tokens, as it requires client changes. It might be possible to construct an svn client auth provider that uses TOTP. However, there is no standardized HTTP protocol that I'm aware of which says "I accept your user/pass, now provide the correct TOTP code". (happy to be educated; my RFC learning is about 10 years old) For svn+ssh, since we control both ends of that conversation, it would be possible to add an additional challenge/response for a 2FA (TOTP?) mechanism. I find this rather dubious, however, as SSH access already implies a very intimate level of access and may already have some level of 2FA incorporated (eg. ASF Infra has 2FA applied to some SSH access). Cheers, -g On Mon, May 19, 2025 at 6:26 AM Peter Balogh <pe...@svnplus.com> wrote: > Hi, > > Thanks, in this case, how would you authenticate using a browser? > > Best regards, > Peter > > On 2025. 05. 19. 12:37, Greg Stein wrote: > > Hi Peter, > > Apologies for not seeing this on the Subversion dev@ list when you first > brought it up. > > Generally speaking, 2FA solutions along this set of requirements, use a > "Bearer token" which is then placed into the Authorization: header. > (sometimes referred to as a Personal Access Token (PAT)). That token is > fetched out of band, placed into a config file, and then picked up for > authentication with the origin server. I've seen this pattern used across > many systems, and I would not like to see a custom 499 HTTP response to > (re)invent the wheel. Nor cookies. Just place the token into the > Authorization header. > > I believe there are four parts here: > 1. a cgi that gets placed on an svn server that can generate a bearer > token for an authenticated user (standard HTTP Basic/Digest, according to > whatever ACLs the server may want to use for access to that cgi). The > bearer token is placed into a sqlite database on the svn server. > 2. the user provides the bearer token to the svn client, which is saved > into a new auth scheme in the svn config directories. "svn.bearer", for > example. > 3. a serf authentication API/mechanism to submit a Bearer token, and svn > will present the bearer token extracted from its config > 4. httpd grows a new "mod_auth_bearer" or "mod_auth_pat" ... and I could > also bet you that such exists, so the above parts could be edited to match > > For the token used in this system, I would suggest Python's > "secrets.token_hex(20)" to generate a hex string of 40 characters, which > represents 160 bits for a token (which I believe should be sufficient for > this system; I'd think the CGI could simply have a constant that local > installations may want to edit). > > Cheers, > -g > > ps. for step 1, I imagine that the Apache Infra team would like to > implement a custom solution to generate the bearer token for its deployment > on ASF systems, but a CGI is a great mechanism for all third parties and to > demonstrate the minimum needs to construct such tokens. > > > On Sun, May 18, 2025 at 4:18 PM Peter Balogh <pe...@svnplus.com> wrote: > >> Hi, >> >> I'm moving this conversation from the subversion dev mailing list for now >> I'm working on adding 2FA to subversion >> >> I have a working PoC of this system, and I'd like to start submitting >> patches. >> The serf changes are attached, what is the process to get approval for >> this? >> >> The patches, configs and scripts to make this work are publicly available >> here: >> https://pub.svnplus.com/repo/2fa/trunk >> >> The implementation uses a special 499 http response code to request 2FA >> auth, I have a working server config that serves this without any server >> side changes https://pub.svnplus.com/repo/2fa/trunk/webdav.conf >> >> The system is running at https://2fa.svnplus.com/repo/2fa/trunk/, and it >> works in the browser and the svn cli with the patches applied, but the svn >> client does not yet save the cookie, so every command needs a 2fa >> >> To access the demo system, use the username: user and password: pass >> The 2FA QR code is displayed on the page >> >> Please let me know, what you think >> >> Best regards, >> Peter >> >> On 2025. 04. 02. 9:25, Daniel Sahlberg wrote: >> >> Hi, >> >> Den mån 31 mars 2025 kl 13:09 skrev Peter Balogh <pe...@svnplus.com>: >> >>> Hi, >>> >>> I'm working on a proof of concept to add multi factor authentication to >>> subversion >>> I have multiple directions, and I'd like to get some feedback from this >>> group before I head down the wrong road >>> Please let me know, if I should read up on any of these, I did not find >>> any recent conversation about these topics >>> >> >> I think this is a very interesting concept! >> >> >>> >>> 1. One option would be to extend the existing Basic auth with another >>> challenge. This would support standard TOTP without external connections >>> I couldn't find any standard way to communicating this through HTTP, my >>> best solution would be to >>> >>> 1.A extend the 401 response with information that the system also needs >>> a TOTP token >>> I've only found the realm string I can use for this without modifying >>> the serf library >>> >>> 1.B reject the username + password attempt with a different 401 >>> This would have to be handled inside the serf library >>> >> >> I don't see a problem modifying Serf if it is needed. Several of the >> Subversion committers are also Serf committers and we can help there. >> >> >>> >>> 2. Provide an external login path instead Basic auth. This would open up >>> using oauth or similar external providers, but a web based provider >>> could be run besides svn as well >>> The server would respond with a 30X response, and the cmdline could >>> print the url for the user to open, login and return to the terminal >>> after authentication >>> This would feel less native, but pretty common these days >>> >> >> I like this idea - I guess this would open up to for example Microsoft >> Entra. >> >> Make sure to use the standard baton/callback method to communicate the >> redirect URL to the client. This way GUI clients (for example TortoiseSVN) >> can implement a more "native" solution to the redirect. >> >> >>> >>> All of the solutions above would result in a HTTP cookie that would be >>> stored encrypted in the auth folder, and sent with every subsequent >>> request >>> >> >> See existing discussions about storing the basic auth password in the >> auth folder. On Windows, there are APIs to encrypt the password linked to >> the user profile. In general no such on Unix, but I assume it could be >> stored in Gnome Keyring/Kwallet/GPG-agent. >> >> >>> >>> Do you have any thoughts or preferences about this? >>> Do you see any technical or security issue with these? >>> >> >> I know very little about the technical details of authentication on the >> http level but I think it would be god to adhere to existing standards as >> much as possible instead of inventing something unique to Subversion. For >> example it would be good if this can be done across a forward/reverse proxy. >> >> If this feature is enabled on a server, it would be impossible to >> authenticate with an older client. Don't know if this is a compatibility >> concern or not, but I think this addition would warrant new releases. >> >> Kind regards, >> Daniel >> >>
