Suggest credentials across different ports of the same site
Reported by
bau...@gmail.com,
Sep 21
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.16 Safari/537.36 Steps to reproduce the problem: 1. go to https://mobile.free.fr 2. double clic password =>Chrome display login/pass for mobile.free.fr but also assistance.free.fr; wifi.free.fr; zimbra.free.fr; imp.free.fr; subscribe.free.fr... compare to 3. go to url with same domain but another tcp port: example https://nas.mydomain.com:5060 (it's example to explain, not test this url) =>Chrome not display password/login saved before for https://nas.mydomain.com:5001 (it's same service, same destination, only nated port because of the ipv4 limitation. (and because not all internet service providers allow all ports, I often have to change to allow access. and that's a problem, I only have one public IPV4) What is the expected behavior? If Chrome choice to display all subdomain password, why this limitation with port, when use TLS ? For https://nas.mydomain.com:5060 must display login/pass for https://nas.mydomain.com:5001 What went wrong? With NAT and ipv4 when outside local network I must use another tcp port. Chrome not understand it's same page but another port and never proposes the login/pass for this. And for other subdomain, Chrome propose all subdomain password/login which have no link between them since they are different services, different servers and a different manager, and often a different security. The forum.domain.com is less secure than www.domain.com for a sales site. Did this work before? N/A Chrome version: 70.0.3538.16 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: +old login/pass without TLS not displayed for TLS website; it would have been nice to be able to use the login/pass of the unsecured site on this same secure site to privilege the use TLS, see to warn by recommending the change of password, because previously the site was not secured; and remove login/pass for this unsecure URL. instead, Chrome does not offer anything, so we re-enter the login / pass that Chrome will store; but Chrome will continue to offer it on the unsecured page of the site.
,
Sep 23
,
Sep 24
The definition of the origin on the web is scheme + host + port (https://tools.ietf.org/html/rfc6454#section-7). This is why https://nas.mydomain.com:5060 treated sepearately form https://nas.mydomain.com:5001 There is a project called PUBLIC SUFFIX LIST(https://publicsuffix.org/). It's common that hosts like wifi.free.fr and zimbra.free.fr represent the same site. Thus, Chrome offers to fill the credentials for one of them on another one. We also share cookies between them. Re: secure vs. non-secure. Currently Chrome does copy the passwords from HTTP over to HTTPS. The plan is to move them soon. Thus, the http credential will be removed if the https version of the site is available. Regarding different ports I don't know how common it's. I'm sure there are the cases when it's undesired. Mike, what do you think about the idea from the security standpoint?
,
Sep 24
Hi, thanks for these informations. I still have not understood everything with this public suffix list, but not found free.fr: = zimbra.free.fr and db57970.free.fr should be considered different site? and public suffix does not mention port, just for cookies and not for login/pass? I add another example with domain free.fr much more annoying, because the second site is personal The personal sites of this provider are "pseudo".free.fr example with my db57970.free.fr, Chrome share login/pass with personal page. It is possible to send login/pass information to another site (not the provider free.fr) Other: if connect and log to my nas with port 8000; when use port 8001 it use the same cookies and not require login. Chrome not share login/pass but share cookies!? For the moment I have often met the opposite, a different host== a different password. But actually in business, when done well, the authentication is global, but the authentication is then the same regardless of the port. I think the cases are comparable, especially if cookies are shared
,
Sep 24
no different treatment according to the port for: HTTP Strict Transport Security Proxy exclusion filter rule (uBlock,adblock) TLS certificat safe browsing/phishing url cookies exception (if not add port) ...
,
Sep 24
vasilii@: If the password manager team is already comfortable sharing credentials across subdomains of a registrable domain, additionally ignoring ports while doing so seems reasonable and doesn't seem to add much incremental risk.
,
Sep 27
Re public suffix list: if db57970.free.fr and mobile.free.fr are different sites then free.fr should include themselves into the PSL. Then we will treat the subdomains accordingly. Re ignoring port: confirmed, it's a reasonable feature request.
,
Oct 1
,
Oct 22
|
||||
►
Sign in to add a comment |
||||
Comment 1 by mattm@chromium.org
, Sep 21