GNOME Bugzilla – Bug 628430
Password are not recognized in URIs
Last modified: 2017-02-13 11:49:56 UTC
Created attachment 169172 [details] example screenshot Nautilus in its address bar accepts URLs like: ftp://server.com ftp://user@server.com But it does not accept URL like: ftp://user:password@server.com that is really common and web browsers understand it. Instead, Nautilus thinks that whole "user:password" is a login name and asks for password. This is wrong, it should split this string using colon and parse the password correctly out of it.
nautilus-2.31.90-1.fc14.x86_64 Fedora 14
I can confirm this bug, it's easily reproduced. Execute 'nautilus ftp://user:pass@somehost' on the command line. The username is treated as 'user:pass', and then the password is requested in the dialog.
I can't work out this bug tracker system, but this bug affects more than just the location bar, I believe it affects any URL handling that nautilus does.
Thanks for your bug report. Nautilus That's because nautilus uses g_vfs_decode_uri function (part of gvfs) to perform URI decoding. That particular function follows RFC 3986. The latter states, in section 3.2.1 ("User Information"): ---- Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used. Applications that render a URI for the sake of user feedback, such as in graphical hypertext browsing, should render userinfo in a way that is distinguished from the rest of a URI, when feasible. Such rendering will assist the user in cases where the userinfo has been misleadingly crafted to look like a trusted domain name (Section 7.6). ---- And section 7.5: ---- 7.5. Sensitive Information URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies). A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public. ---- Now, nautilus (or rather gvfs) should probably be a bit smarter and detect whether the login contains a colon, and strip everything from the colon to the @ sign, so that the password is (a) not transmitted plaintext over the net, (b) warn the user that this particular format is deprecate. Or just ignore the RFC and implement this feature to conform to existing web browsers...
Can you advise a workaround for this? I'd like to invoke FTP URLs with password via the shell.
I understand the RFC in means of rendering. The password should not be shown. But I would advise to accept it as an input. That is exactly the case in Firefox. It accepts the format as an input, but then renders it the address bar without the password.
I just wanted to report this issue. It is quiet annoying as people are used to be able to use these urls. I am not sure how to read the RFC yet.
This looks like a duplicate of bug 538432 [1] though it refers to a different memo, RFC1738. * [1] https://bugzilla.gnome.org/show_bug.cgi?id=538432
I think the component of this bug is off. I can reproduce it with plain gvfs-mount on the commandline: gvfs-mount ftp://user:pass@server/
*** Bug 538432 has been marked as a duplicate of this bug. ***
-> gvfs
While we can detect, decode and use password from the URI given (not saving it in keyring), the way GIO has been designed you'd still see the original URI everywhere. It's a key string that makes it possible to match existing mounts. So that ftp://user:pass@server/ and ftp://user@server/ would be two different mounts. And that would create another level of confusion, just like ftp://user@server/ and ftp://server/ do.
I think bug #520915 should be marked as a duplicate of this one.
*** Bug 520915 has been marked as a duplicate of this bug. ***
I would like to see this feature implemented. It is handy to be able to open locations from the command line with the password included.
I am afraid of that we don't want support passwords in URIs, because it is a security issue. However, we should remove them from the usernames at least if it is not fixed already...
From https://tools.ietf.org/html/rfc3986#section-3.2.1: Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.
Created attachment 343900 [details] [review] client: Ignore everything after first colon in userinfo Use of the format "user:password" in the userinfo field is deprecated and applications should not render as clear text any data after the first colon as per rfc3986. Passwords have never been handled in userinfo fields by GVfs, however, they are still part of the usernames, which is wrong. Let's ignore such data in userinfo fileds.
Attachment 343900 [details] pushed as 2417271 - client: Ignore everything after first colon in userinfo