Dear,
I try to use app password today for my solid explorer on one device,
I was surprised when it was working with my another device.
Actually one app password should only work with one app/or single time, if created for temporary use.
Please somebody look into this.
Thanks,
Actually this is working as designed.
The idea behind this is:
- the user creates one app password for each app
- uses a different password for each app
- (optional) uses a different app password for the same app on a different device
- can see in Nextcloud GUI which “app” (or device) logged in last
- can discover compromised passwords due to unexpected login behavior
- can revoke the compromised password and set a new one, without the need to change the “normal” password for your account (security gain)
Not sure how you use it, but Nextcloud cannot (or at least right now does not) check if only the app you planned to use (for this app password) actually used it (and not another app). There is no matching by name, like I name my app password “Outlook” and Nextcloud automatically checks if only MS Outlook is logging in with that password.
At max you could open a feature request and ask for some mechanism. Maybe like:
- with first login of any client with a new app password, store the user agent string in DB
- with all logins afterwards compare the user agent string with the one stored in DB for that app pw
- if user agent string differs, block login
The downside I can think of, with such an feature: if the user agent string slightly changes, the login is blocked. Furthermore I believe the user agent string can be manipulated (in the meaning of adapted) by attackers.
Regarding
This app password is valid until you revoke it. It wasn’t intended to create a one time password. Doesn’t seem useful to me anyway. If you want to grant access for a limited time only, you can either:
- revoke the app password manually after the desired time
- share the needed data password protected with an expiration date
- create a feature request for an occ command to delete an app password by command line (option for cronjob)
Hope this helps.
Dear,
This is what I want
As per you ask to request
This the point from your suggestions
- with first login of any client with a new app password, store the user agent string in DB
- with all logins afterwards compare the user agent string with the one stored in DB for that app pw
- if user agent string differs, block login
@Schmu, not true: the app-token is invalid as soon as you change your normal password.
Refs:
- my related comment in another thread
- Issue #2581, where it comes out that the invalidation is an intentional design decision
- PR 9485, which should bring it inline with your (and my) expected behavior, planned for NC14 with no plan for a backport to NC13
@r2evans
You referencing an issue (=bug). So sure, it is not working as described/ intended. That’s just the nature of a bug 
Technically, they are calling it “not a bug” since it is working as they designed. That would make it (in my mind) a design flaw, something with which I take issue :-). I can kind of understand why they designed/implemented it the way they did: a robust way to support 2FA for web use and non-2FA for specific clients. And if I understand their initial implementation correctly, I understand why they are hesitant to backport to NC13: it’s a breaking change.
But I don’t want to hijack this conversation, which originates on the perception that an app-password should only be tied to a single device (and even single app on that device). I do not see app-tokens that way universally, though I can see it as a secure extension of the premise of app-tokens. (I can see it requiring an interactive hand-shaking to mitigate MITM issues.)
As I think about it, your suggestion (March 11) to use the user-agent string is novel in that it instantly allows any existing app to become singular-app-token compliant. (Other suggestions I have typed and since deleted were not backward-compatible like this.) You are right that string-changes (e.g., client upgrades) will cause some angst. For example, if I look at the user-agents from my logs:
"DAVdroid/1.11.5-gplay (2018/06/17; dav4android; okhttp/3.10.0) Android/8.1.0"
"Google Pixel"
"Mozilla/5.0 (Android) Nextcloud-android/3.2.1"
"Mozilla/5.0 (Android) ownCloud-android/3.2.1"
"Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)"
"Mozilla/5.0 (Windows) mirall/2.2.4 (build 2) (Nextcloud)"
"Mozilla/5.0 (Windows) mirall/2.3.2 (build 6928)"
"Mozilla/5.0 (Windows) mirall/2.3.3 (build 1) (Nextcloud)"
"Mozilla/5.0 (Windows) mirall/2.4.1 (build 9270)"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0"
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 Lightning/6.2"
"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36"
"Thunderbird CardBook/30.1 Lightning/6.2"
"Wget/1.17.1 (linux-gnu)"
You can immediately see that upgrading from nextcloud desktop client would immediately negate the app-token. Do you think removing any numbers/whitespace (to negate version changes) would compromise functionality and/or security? It would make the above this:
"DAVdroid/..-gplay(//;davandroid;okhttp/..)Android/.."
"GooglePixel"
"Mozilla/.(Android)Nextcloud-android/.."
"Mozilla/.(Android)ownCloud-android/.."
"Mozilla/.+(compatible;UptimeRobot/.;http://www.uptimerobot.com/)"
"Mozilla/.(Windows)mirall/..(build)(Nextcloud)"
"Mozilla/.(Windows)mirall/..(build)"
"Mozilla/.(Windows)mirall/..(build)(Nextcloud)"
"Mozilla/.(Windows)mirall/..(build)"
"Mozilla/.(WindowsNT.;Win;x)AppleWebKit/.(KHTML,likeGecko)Chrome/...Safari/.Edge/."
"Mozilla/.(WindowsNT.;Win;x;rv:.)Gecko/Firefox/."
"Mozilla/.(WindowsNT.;WOW;rv:.)Gecko/Thunderbird/.Lightning/."
"Mozilla/.(WindowsNT.;Win;x)AppleWebKit/.(KHTML,likeGecko)Chrome/...Safari/."
"ThunderbirdCardBook/.Lightning/."
"Wget/..(linux-gnu)"
which looks funny, but the differences are much smaller (though it still appears that nextcloud desktop clients use inconsistent user-string verbiage). More-robust number-removing regexes could be used …