[opensuse] browser and passwords and RSA, oh my.
I have a very unusual situation. I am trying to log in to a web site (https://www.zf-laser.com if you are curious) from either Firefox (72.0.2) or Chrome (79.0.3945.130) on Tumbleweed. I enter the password, but it is not accepted. Both browsers change the password I have entered into a long string that starts with "rsa:". I am guessing this is what they send. And, when Firefox offers to keep the password, I see that it is this same altered string, not the one I entered. I can log in to other sites (e.g. OBS). But not this one. I have no idea what is happening. Especially since both browsers do the same thing. Any ideas? A Google search did not seem to me to show anything related to this. Just stuff generally about RSA and passwords in browsers. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2020 01:28 AM, Roger Oberholtzer wrote:
I have a very unusual situation. I am trying to log in to a web site (https://www.zf-laser.com if you are curious) from either Firefox (72.0.2) or Chrome (79.0.3945.130) on Tumbleweed.
I enter the password, but it is not accepted. Both browsers change the password I have entered into a long string that starts with "rsa:". I am guessing this is what they send. And, when Firefox offers to keep the password, I see that it is this same altered string, not the one I entered.
I can log in to other sites (e.g. OBS). But not this one. I have no idea what is happening. Especially since both browsers do the same thing.
Any ideas? A Google search did not seem to me to show anything related to this. Just stuff generally about RSA and passwords in browsers.
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation) The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 19, 2020 at 10:08 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation)
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
I think I agree. But I am still curious why I see the rsa: string. That is, I guess, what will be saved in the browser's password list. Which is good as it is not saving plain text. But should the browser really be replacing the original password in the dialog with this string? Is it because this is an https: site that the password expected by the remote is the rsa: string version of the password? Should the browser really be showing that to me, even it if is what it is sending? Of course my Windows colleagues have no problem logging in. Sigh. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2020 03:51 AM, Roger Oberholtzer wrote:
I think I agree. But I am still curious why I see the rsa: string. That is, I guess, what will be saved in the browser's password list. Which is good as it is not saving plain text. But should the browser really be replacing the original password in the dialog with this string?
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's. Here is a good link: https://crackstation.net/hashing-security.htm Is it because this is an https: site that the password
expected by the remote is the rsa: string version of the password? Should the browser really be showing that to me, even it if is what it is sending?
Now how it is hashed, rsa, or a different sha variant: https://csrc.nist.gov/projects/hash-functions For whatever reason, your browser and this one site may be talking apples and oranges because the site is looking for some non-standard MS predicate for the hashed password, different salt, etc...
Of course my Windows colleagues have no problem logging in. Sigh.
Never fails... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/02/2020 18.01, David C. Rankin wrote:
On 02/19/2020 03:51 AM, Roger Oberholtzer wrote:
I think I agree. But I am still curious why I see the rsa: string. That is, I guess, what will be saved in the browser's password list. Which is good as it is not saving plain text. But should the browser really be replacing the original password in the dialog with this string?
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 19/02/2020 18.01, David C. Rankin wrote:
On 02/19/2020 03:51 AM, Roger Oberholtzer wrote:
I think I agree. But I am still curious why I see the rsa: string. That is, I guess, what will be saved in the browser's password list. Which is good as it is not saving plain text. But should the browser really be replacing the original password in the dialog with this string?
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords.
Yeah, I don't see how it could be otherwise for plain userid+passwd logins. -- Per Jessen, Zürich (5.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-02-19 12:05 PM, Carlos E. R. wrote:
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords.
I assume you're referring to the saved logins, which include the ID and password for a site. Are plain text passwords actually sent to the server? Or a hash? There's a bit of a difference between one's own computer and sending plain text passwords over the Internet. BTW, I remember the days when you could read passwords with Wireshark (then known as Ethereal) or other packet capture. When's the last time you used telnet? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-02-19 12:05 PM, Carlos E. R. wrote:
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords.
I assume you're referring to the saved logins, which include the ID and password for a site. Are plain text passwords actually sent to the server?
It depends. Apache authentication can do it, but with encrypted connections, I would expect plaintext.
BTW, I remember the days when you could read passwords with Wireshark (then known as Ethereal) or other packet capture. When's the last time you used telnet?
This afternoon. :-) -- Per Jessen, Zürich (5.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-02-19 12:47 PM, Per Jessen wrote:
I assume you're referring to the saved logins, which include the ID and password for a site. Are plain text passwords actually sent to the server? It depends. Apache authentication can do it, but with encrypted connections, I would expect plaintext.
And how would they be stored on the server? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/02/2020 20.15, James Knott wrote:
On 2020-02-19 12:47 PM, Per Jessen wrote:
I assume you're referring to the saved logins, which include the ID and password for a site. Are plain text passwords actually sent to the server? It depends. Apache authentication can do it, but with encrypted connections, I would expect plaintext.
And how would they be stored on the server?
In my case, it is a an embedded Linux machine, and the password is hardcoded. I just google the community sites of the machines and read the password. It is "l1nux" :-P I have not tried to change it, I think it may be read only and don't want to risk bricking the machine: cer@Legolas:~> ssh -X cer@remote_internet_address ... cer@Isengard:~> telnet moria Trying 192.168.1.2... Connected to moria. Escape character is '^]'. Moria login: root Password: ----------------------------------------- Host: Moria Version FW: Version SIESTA: 2.04.00 SIESTA-Lemmi-13 Actualizaci�n: 2012-02-22 15:26:09 ----------------------------------------- [root@Moria:~]# [root@Moria:~]# uname -a Linux Moria 2.4.21-xfs #646 Wed Aug 3 10:01:46 CEST 2005 mips unknown [root@Moria:~]# l /etc/passwd /etc/passwd [root@Moria:~]# ls -l /etc/passwd lrwxrwxrwx 1 root root 16 Feb 19 20:01 /etc/passwd -> /data/etc/passwd [root@Moria:~]# -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
James Knott wrote:
On 2020-02-19 12:47 PM, Per Jessen wrote:
I assume you're referring to the saved logins, which include the ID and password for a site. Are plain text passwords actually sent to the server? It depends. Apache authentication can do it, but with encrypted connections, I would expect plaintext.
And how would they be stored on the server?
Hashed and salted. -- Per Jessen, Zürich (5.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/02/2020 18.31, James Knott wrote:
On 2020-02-19 12:05 PM, Carlos E. R. wrote:
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords.
I assume you're referring to the saved logins, which include the ID and password for a site.
Correct. If you set a master password they are encrypted in some file, but firefox is able to recover the plain login/pass. It has to.
Are plain text passwords actually sent to the server? Or a hash? There's a bit of a difference between one's own computer and sending plain text passwords over the Internet.
If the page uses https, it is secure sending.
BTW, I remember the days when you could read passwords with Wireshark (then known as Ethereal) or other packet capture. When's the last time you used telnet?
A week ago :-P -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On 02/19/2020 11:05 AM, Carlos E. R. wrote:
On 19/02/2020 18.01, David C. Rankin wrote:
On 02/19/2020 03:51 AM, Roger Oberholtzer wrote:
I think I agree. But I am still curious why I see the rsa: string. That is, I guess, what will be saved in the browser's password list. Which is good as it is not saving plain text. But should the browser really be replacing the original password in the dialog with this string?
Yes, the actual password is never stored anywhere. That has been the normal practice since at least the 80's or early 90's.
Not so. Firefox does store the actual passwords.
Not so: https://security.stackexchange.com/questions/109140/how-to-read-the-key3-db-... -- David C. Rankin, J.D.,P.E.
On Thu, Feb 20, 2020 at 5:28 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
https://security.stackexchange.com/questions/109140/how-to-read-the-key3-db-...
That makes sense to me. I was originally suspicious that the key stored in the db was somehow being sent to the server instead of the unencrypted version. But I could not see how both Firefox and Chrome could do the same thing. Some JavaScript in the page itself must be the culprit. Probably they never tried from other than Windows. I wonder if they tried from a Mac. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
W dniu 19.02.2020 o 10:08, David C. Rankin pisze:
On 02/19/2020 01:28 AM, Roger Oberholtzer wrote:
I have a very unusual situation. I am trying to log in to a web site (https://www.zf-laser.com if you are curious) from either Firefox (72.0.2) or Chrome (79.0.3945.130) on Tumbleweed.
I enter the password, but it is not accepted. Both browsers change the password I have entered into a long string that starts with "rsa:". I am guessing this is what they send. And, when Firefox offers to keep the password, I see that it is this same altered string, not the one I entered.
I can log in to other sites (e.g. OBS). But not this one. I have no idea what is happening. Especially since both browsers do the same thing.
Any ideas? A Google search did not seem to me to show anything related to this. Just stuff generally about RSA and passwords in browsers.
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation)
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
Ackchyually... ;) Browsers send passwords in plaintext and servers do the hashing. That's why sometimes you can read in news that somewhere passwords were saved in plaintext in logs. I haven't looked at this website, but it seems that it does some custom client-side hashing in javascript, before sending form data. By the way, are you sure that https://www.zf-laser.com is correct address? I see no login form anywhere there.
W dniu 19.02.2020 o 11:01, Adam Mizerski pisze:
W dniu 19.02.2020 o 10:08, David C. Rankin pisze:
On 02/19/2020 01:28 AM, Roger Oberholtzer wrote:
I have a very unusual situation. I am trying to log in to a web site (https://www.zf-laser.com if you are curious) from either Firefox (72.0.2) or Chrome (79.0.3945.130) on Tumbleweed.
I enter the password, but it is not accepted. Both browsers change the password I have entered into a long string that starts with "rsa:". I am guessing this is what they send. And, when Firefox offers to keep the password, I see that it is this same altered string, not the one I entered.
I can log in to other sites (e.g. OBS). But not this one. I have no idea what is happening. Especially since both browsers do the same thing.
Any ideas? A Google search did not seem to me to show anything related to this. Just stuff generally about RSA and passwords in browsers.
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation)
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
Ackchyually... ;)
Browsers send passwords in plaintext and servers do the hashing. That's why sometimes you can read in news that somewhere passwords were saved in plaintext in logs.
I haven't looked at this website, but it seems that it does some custom client-side hashing in javascript, before sending form data.
By the way, are you sure that https://www.zf-laser.com is correct address? I see no login form anywhere there.
(about previous email: first I wrote second paragraph, then went on to look at the site, then wrote the third and forgot to edit the second) So I found the login form (https://www.zf-laser.com/Download.165.0.html?&L=1) and as I predicted, it contains javascript that encrypts password before sending. So this is what happens: - you enter you password - you click "Loging" or press enter - javascript code kicks in, that modifies the password that you have entered - browser sends encrypted password If you want to save your password in browser, you might first save the "rsa:..." thing and then edit it in browser's password manager. If it's not accepted by server it might be because it's just wrong password.
On 19/02/2020 11.10, Adam Mizerski wrote:
W dniu 19.02.2020 o 11:01, Adam Mizerski pisze:
W dniu 19.02.2020 o 10:08, David C. Rankin pisze:
On 02/19/2020 01:28 AM, Roger Oberholtzer wrote:
...
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation)
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
Ackchyually... ;)
Browsers send passwords in plaintext and servers do the hashing. That's why sometimes you can read in news that somewhere passwords were saved in plaintext in logs.
I haven't looked at this website, but it seems that it does some custom client-side hashing in javascript, before sending form data.
I would think so.
By the way, are you sure that https://www.zf-laser.com is correct address? I see no login form anywhere there.
(about previous email: first I wrote second paragraph, then went on to look at the site, then wrote the third and forgot to edit the second)
So I found the login form (https://www.zf-laser.com/Download.165.0.html?&L=1) and as I predicted, it contains javascript that encrypts password before sending.
So this is what happens: - you enter you password - you click "Loging" or press enter - javascript code kicks in, that modifies the password that you have entered - browser sends encrypted password
If you want to save your password in browser, you might first save the "rsa:..." thing and then edit it in browser's password manager.
If it's not accepted by server it might be because it's just wrong password.
Or wrong coding. If it works on Windows and not in Linux, there would be some difference in the code or its interpretation. Of course, Roger has to try himself on Windows. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, Feb 19, 2020 at 11:01 AM Adam Mizerski <adam@mizerski.pl> wrote:
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
Except for my Windows friends for whom it works. Something that they only tested on Windows? I will see which browsers they are using to get access.
Ackchyually... ;)
Browsers send passwords in plaintext and servers do the hashing. That's why sometimes you can read in news that somewhere passwords were saved in plaintext in logs.
I wasn't sure about this. So if the browser is doing some manipulation of the password and that results in the rsa: string that it wants to be sent to the server, I wonder why the login is failing.
I haven't looked at this website, but it seems that it does some custom client-side hashing in javascript, before sending form data.
By the way, are you sure that https://www.zf-laser.com is correct address? I see no login form anywhere there.
The login is when you try to download software. General access to the site is open. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 19 Feb 2020 13:37:44 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 19, 2020 at 11:01 AM Adam Mizerski <adam@mizerski.pl> wrote:
The real question is why does this one site not accept what you are typing in while other sites work fine? The initial first thought is that site is broken -- so no matter what browser you use -- it doesn't work. That would seem to me to be the simplest explanation...
Except for my Windows friends for whom it works. Something that they only tested on Windows? I will see which browsers they are using to get access.
Could be a different javascript engine as well as a different browser.
Ackchyually... ;)
Browsers send passwords in plaintext and servers do the hashing. That's why sometimes you can read in news that somewhere passwords were saved in plaintext in logs.
I wasn't sure about this. So if the browser is doing some manipulation of the password and that results in the rsa: string that it wants to be sent to the server, I wonder why the login is failing.
I haven't looked at this website, but it seems that it does some custom client-side hashing in javascript, before sending form data.
By the way, are you sure that https://www.zf-laser.com is correct address? I see no login form anywhere there.
The login is when you try to download software. General access to the site is open.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/02/2020 10.08, David C. Rankin wrote:
On 02/19/2020 01:28 AM, Roger Oberholtzer wrote:
I have a very unusual situation. I am trying to log in to a web site (https://www.zf-laser.com if you are curious) from either Firefox (72.0.2) or Chrome (79.0.3945.130) on Tumbleweed.
I enter the password, but it is not accepted. Both browsers change the password I have entered into a long string that starts with "rsa:". I am guessing this is what they send. And, when Firefox offers to keep the password, I see that it is this same altered string, not the one I entered.
I can log in to other sites (e.g. OBS). But not this one. I have no idea what is happening. Especially since both browsers do the same thing.
Any ideas? A Google search did not seem to me to show anything related to this. Just stuff generally about RSA and passwords in browsers.
What Firefox (and chrome) are doing is just plain-old normal password hashing. You never store the plain password, instead a hash of the password is stored. When you enter a password to login, what you enter is hashed and then compare against the stored hash (prevent somebody making off with your passwords if they steal your passwords file, etc... -- normal cryptographic operation)
Not so. On "see stored password" of firefox I see the plain password as I entered it in full clear text of all sites I told FF to save the password. How it stores the password internally is something else. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (7)
-
Adam Mizerski -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
James Knott -
Per Jessen -
Roger Oberholtzer