Issue metadata
Sign in to add a comment
|
Updated password issue in Chrome Version 49.0.2623.112 m
Reported by
udayandu...@gmail.com,
Apr 13 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Steps to reproduce the problem: 1. Open the Chrome Version 49.0.2623.112 m and open the login page of a website. 2. Enter username and password and let chrome remember the password. 3. Update the password in the settings and logout. 4. Re-login (system will show error message, which is expected) 5. Enter the newly updated password manually and let chrome update the newly password. 6. Logout again. 7. Try re-login with latest credentials. What is the expected behavior? System should proceed with updated password and let user logging in. What went wrong? System is showing error message even after chrome has remembered the updated password, which is a defect. Did this work before? N/A Chrome version: 49.0.2623.112 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 21.0 r0 I have recently tested this and watching the same for last couple of months just to make sure whether I am correct or not and now I am pretty sure that this is a defect which I would like to request to Google to resolve. Many thanks. May I know if I can get any rewards for this.
,
Apr 16 2016
Yes it is functional though I have opted for security issue as because the matter relates to password issue. But please mention if I have the privilege to update the defect type from security issue to functional.
,
Apr 21 2016
Unable to reproduce the issue on windows using chrome version 50.0.2661.75 with the URL Twitch.tv. Able to login to site without any error with chrome updated password. Please find the attached screen shot for the same. udayandutta08@ Request you please try the issue by upgrading chrome to latest stable and if the issue still persists please provide us the sample URL to triage the issue further. Thanks,
,
Apr 21 2016
Hi Team, yes I have checked and found that Google Chrome is up to date. With the latest update also, the issue still persists. Please try with the sample url : http://www.jabong.com/ Also, please find the attachment here for the reference. To triage the issue further, kindly mention what would be the status of the bug as the bug status is still 'unconfirmed'.
,
Apr 22 2016
udayandu...@ Could you please go to chrome://settings/passwords after clicking on "Update" button and check what password is saved there for this site? Are there only one or multiple entries in chrome://settings/passwords password list for this site?
,
Apr 22 2016
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2016
Hi Team, as suggested by dvadym@chromium.org, I have gone through chrome://settings/passwords and found some serious issues. I would like to request to all of you to kindly check the attachment here for reference. Few questions : 1. If you let chrome to save the password for once and if you do not clear it from chrome://settings- clear browsing history, then why chrome is asking the option to 'save' again for a new password instead of asking for 'update'? 2. In chrome://settings/passwords, we are seeing that passwords are storing in a stack for same website. More stunningly, system is saving the password for the second time and adding it in a second row in chrome://settings/passwords. 3. Moreover, while chrome is updating the password, it is actually updating the password that has been entered by the system itself in the second row but while trying to logging in with updated password, system accesses the password that was stored initially from the top in settings. Hence, system is showing the error message while logging in. One thing I have noticed (I have experienced this same issue in my office mail also). - In some websites (e.g. twitch.tv, amazon and many more), while changing the password from their account settings, chrome asks for updating the password and does not consist any issue. As because in that case the scenario is, login to that website-> go to settings->change password->chromes asks to update password->logout->relogin successfully. -whereas, in some other websites, it is designed that after updating passwords from secure section->logout and while manually enter with updated password (followed by login button), chrome asks to update the password. In both scenarios, they are valid in their own ways. As per chrome's point of view, it is restricted to save and update passwords accordingly for the second type of websites.
,
Apr 29 2016
vadym@, could you please look into c#7? Thank you!
,
May 3 2016
Thanks a lot for the comprehensive description and the video. There are 2 issues: 1.There are 2 sign-in forms: one on the main page and one on jabong.com/account/profile. The former sign-in form is on http address (non-secure protocol), the latter is on https (secure protocol, green lock in address bar). From security reasons Chrome Password Manager considers sites with different protocols to be different and doesn't fill one credentials in another (you can notice on the video that when you go to jabong.com/account/profile Chrome doesn't fill stored credentials, since they were saved on sign-in form on different origin). Also if you move mouse over address of saved credentials on chrome://settings/passwords you can see a tooltip with addresses, and only one of them is on https. Unfortunately we can't do anything here, since from security reasons it's considered unsafe fill http credentials into https forms and vice versa. I think it's worth for us to think how to improve notification about this. I would recommend you to use only https password forms on this site. 2.Chrome doesn't update password on change password. As you mentioned for some sites Chrome proposes to update password immediately. It's supposed to do so for any site, but sometimes it fails, by various of reasons. Could you please record a log, that I could understand why it doesn't work, for this: Could you please also open chrome://password-manager-internals/ in a second tab, then change password in the first one, and then share the logs? (The logs won't contain your username or passwords, just the structure of forms seen and the events observed by Chrome).
,
May 4 2016
Hi dvadym@chromium.org, as suggested, I have shared the attachment along with the logs. Please find the same. If you find that the logs need to be re-logged then please mention the same as I have kept the logs before changing password and after changing passwords (just for confirmation).
,
May 17 2016
Hi Team, With due respect, is there any update on the bug#603192 ? As far my concern, I have sent the logs as suggested. Please reply.
,
May 18 2016
Sorry, I've missed your answer. Thanks for a log, according to the log Chrome password manager misses submission of a change password form. I have plans to improve submission detection in Chrome password manager. I duplicate this bug to a tracking bug of improving form submission detection.
,
May 18 2016
Chrome Password Manager fails to save/update password for non-secure protocol which was mentioned in Comment 9. This defect was raised for non-secure protocol only. I have a doubt whether in Issue 597309 has any mention of secure or non-secure protocol in the chrome password manager. As chrome password manager did not fail for secure protocol. Could you please re-check this defect description only as I believe this defect is not subjected to be merged/duplicated and change the status of this defect as it should not be merged with any other defect. Thank you.
,
May 24 2016
Yeah, it makes sense. As I wrote, the only thing that we can do is to add some notification that credentials on other protocol is available. I've created a bug 614342 for tracking progress on this.
,
May 28 2016
Okay dvadym@chromium.org, so how can I get the reward for this?
,
May 30 2016
Unfortunately, this does not qualify for a reward under https://www.google.com/about/appsecurity/chrome-rewards/
,
Jun 1 2016
Hi battre@chromium.org, Few facts that I want to mention are - 1. The defect is not pointing any other common defects regarding Google Chrome password manager. The defect description and comments are signifying about the same. This defect has had the status 'assigned' after several reviews from your team. I would like to request you to review the description and conversations, if you have the privilege. 2. From comment 12, you can see that the developer has changed this defect status into 'duplicate' and merged into #597309 which has got no similarity with #603192. You can always check the defect description of that one (#597309) and in fact if you open that defect (#597309) you can see that there is an another defect linked with #597309. The latter one has defect id #547494. Interestingly, #547494 was raised on October 25, 2015 and it is merged into #597309 which was raised on March 23, 2016. This becomes confusing when you merge one defect with it's later one and that too also with different defect descriptions. In the defect that I have raised, in comment 7, I have provided a comprehensive description to help finding the issues which was accepted in comment 9, the developer has mentioned about secure and non-secure protocols, which was actually prominent interms of the defect description that I have stated. Password-manager has issues with non-secure protocol which in my case is reflected. You can check the videos uploaded by me. 3. Besides, later on, stating the same to the respective developer, the corresponding person has managed to open a new defect and merged my defect into that one (#614342) in comment 14, and made my defect duplicated. This was done from google team end only, which was a bit surprising. Is there any protocol in Google, where the defect can be duplicated which was raised from public end and raise another defect from Google team's end and then link it? However, during the conversations, developers accepted that #603192 is a valid defect and thanked me for elaborating and corresponding videos as proof. One respective developer has managed to ask for logs and that too I have sent it but then the person has raised a new defect and merged mine. Hence, it is not subjected to be in status 'duplicate' and hence it is not subjected to be excluded or closed or duplicated. Again I am requesting to you to kindly go through once from the beginning of this defect (#603192) and comments. I do work as a QA in an IT firm and I have experienced about testing methodologies for more than 3 years and I am still hoping that I will get a chance for it. It will be really appreciable if I can get any valueable feedback hereonwards.
,
Jun 2 2016
I am sorry. Chrome rewards only reports of security bugs and this concerns neither Chrome's security threat model nor does it impact the user's security. See https://dev.chromium.org/developers/severity-guidelines for examples. This is a functional bug in a heuristic of the password manager.
,
Jun 6 2016
This may not be a direct threat from Chrome's security threat model point of view but as you can see from any user's end that once the user is able to save/update the password and tries to re-login, the person is facing issues with login. Also, passwords of some websites that are in use for mails or chats, can be changed/updated from other websites as because of there is dependency on other websites. So by changing the passwords from that end, at a glance it becomes difficult to understand if there is any issue in the code base of the corresponding website(s) or in chrome-password-manager. Hence, even after changing passwords, isn't it enough to consider this as a potential security bug? This is of course a functional bug. All functional bugs may not be security bugs, but isn't this one ? One friendly request, if you find this bug to be helpful in identifying some loop holes in these applications, then may I expect myself as part of your team in near future? That will be much more than rewards.
,
Jun 21 2016
This may not be a direct threat from Chrome's security threat model point of view but as you can see from any user's end that once the user is able to save/update the password and tries to re-login, the person is facing issues with login. Also, passwords of some websites that are in use for mails or chats, can be changed/updated from other websites as because of there is dependency on other websites. So by changing the passwords from that end, at a glance it becomes difficult to understand if there is any issue in the code base of the corresponding website(s) or in chrome-password-manager. Hence, even after changing passwords, isn't it enough to consider this as a potential security bug? This is of course a functional bug. All functional bugs may not be security bugs, but isn't this one ? One friendly request, if you find this bug to be helpful in identifying some loop holes in these applications, then may I expect myself as part of your team in near future? That will be much more than rewards. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tsepez@chromium.org
, Apr 14 2016