What in the world is this?

[Selene Gregoire]

I can't log in because this is on my screen and I have no idea what it is or how to fix it. Obviously I can't log in to ask for help in the FS support group. Any0ne else ever see this and what did you do to fix it? Am I going to have to reenter all my accounts just because I switched ISPs?  I've switched ISPs several times over the years and never had this until now.

Edited August 9, 2019 by Selene Gregoire

[MoiraKathleen]

I've had that message come up a few times before.  It's been a long time since I've seen that, so I don't remember exactly what is was about my system that had changed.  However, just typing in my username and password was all that I needed to do.  (I typically do not store my username or password anyway, so for me it really wasn't an issue to enter them). 

[Fritigern Gothly]

Something must have changed on your system.  Judging by your reaction I don;t think it's a hardware change although it can happen on laptops when changing from wifi to ethernet, or the other way around. Another thing that could have happened is that the file which stores your credentials has become corrupted for one reason or another.
One more factor which I think could play a role here, are software updates to key components of your operating system.

The solution is simple, however. If there are no changes that you can undo to your system's configuration (which would restore your previous credentials), then all there's left is entering your username and password which will then be saved to a new credentials file. Your previously stored credentials will, however, be overwritten and be lost forever.

 

BTW, I personally don't see why FS should hash your login credentials against the UUID of one or more components on your system. It is very inconvenient for the end user.

[Whirly Fizzle]

https://wiki.firestormviewer.org/fs_stored_passwords#failed_to_decode_login_credentials

BUG-139291 - Windows product key not suitable as unique machine key

[Selene Gregoire]

I found it.

https://wiki.firestormviewer.org/fs_stored_passwords

Thanks all. 

Got rid of the message but now I still have to re-enter all my accounts. Not what I was trying to do... dammit. Oh well. *sighs*

I don't store passwords only user names and I was trying to preserve the user names.

Edited August 9, 2019 by Selene Gregoire

[Bree Giffen]

How many alts do you have for this to be a hassle? 😱

[Selene Gregoire]

23 minutes ago, Bree Giffen said:

How many alts do you have for this to be a hassle? 😱

I have 4 active accounts and one inactive.

Edited August 9, 2019 by Selene Gregoire

[LittleMe Jewell]

5 hours ago, Bree Giffen said:

How many alts do you have for this to be a hassle? 😱

I currently have 17 login ids stored in Firestorm

[Kimmi Zehetbauer]

Sometimes that happens to me --- the log in stuff gets wiped. Lucky I only have 2 avis to keep track of.

[Lillith Hapmouche]

14 hours ago, Selene Gregoire said:

I don't store passwords only user names and I was trying to preserve the user names.

Firestorm's back-up utility should be able to handle that, I'd say, even without the passwords.
So once you've entered all your regular accounts, it's worth the time to store that login data, so you can happily restore it from your back-up.

Despite that message shown in the original post, you can still click the OK button and manually type in your login. 

[Gabriele Graves]

1 hour ago, Lillith Hapmouche said:

Firestorm's back-up utility should be able to handle that, I'd say, even without the passwords.
So once you've entered all your regular accounts, it's worth the time to store that login data, so you can happily restore it from your back-up.

Despite that message shown in the original post, you can still click the OK button and manually type in your login. 

Sadly, this has not been my experience.  If the viewer cannot decrypt the credential store you don't get the usernames either.  Further more if you setup the account details, backup and then something changes on your system such that the decoding is no longer possible, then the restoring will not work either.  This is presumably because the backup has a copy of the credential store from before the decryption key changed and the new key cannot be used to decrypt the backup copy of the credential store.  The only thing you can do is to try to put the system back into the state it was before the key changed and revert the key to the previous value.

For example, on my setup sometimes a rare and random glitch happens during PC sleep and my network card loses its IP address when it wakes up.  Sometimes I don't notice and try to start FS.  FS then tells me that it cannot decode the credential store just like Selene sees.  Now, at this point, I know I haven't changed anything in my setup so after a few moments of wondering WTF, I realise that the IP address has been lost which has triggered a key change for FS.  Luckily, I know how to reacquire a new IP address and so I do that and after I restart FS, Hey Presto, the credential store can be decrypted again because the key is now back to the same value as before and my login details are available again.

[Selene Gregoire]

6 hours ago, Lillith Hapmouche said:

Firestorm's back-up utility should be able to handle that, I'd say, even without the passwords.
So once you've entered all your regular accounts, it's worth the time to store that login data, so you can happily restore it from your back-up.

Despite that message shown in the original post, you can still click the OK button and manually type in your login. 

The whole point is to not have to type in the user name every time I log in.

 

4 hours ago, Gabriele Graves said:

Sadly, this has not been my experience.  If the viewer cannot decrypt the credential store you don't get the usernames either.  Further more if you setup the account details, backup and then something changes on your system such that the decoding is no longer possible, then the restoring will not work either.  This is presumably because the backup has a copy of the credential store from before the decryption key changed and the new key cannot be used to decrypt the backup copy of the credential store.  The only thing you can do is to try to put the system back into the state it was before the key changed and revert the key to the previous value.

For example, on my setup sometimes a rare and random glitch happens during PC sleep and my network card loses its IP address when it wakes up.  Sometimes I don't notice and try to start FS.  FS then tells me that it cannot decode the credential store just like Selene sees.  Now, at this point, I know I haven't changed anything in my setup so after a few moments of wondering WTF, I realise that the IP address has been lost which has triggered a key change for FS.  Luckily, I know how to reacquire a new IP address and so I do that and after I restart FS, Hey Presto, the credential store can be decrypted again because the key is now back to the same value as before and my login details are available again.

The only thing that changed on my pc was I had to update it from the 18xx to the 19xx because they are dropping support for 18xx. And I had been logged in after the ISP change so I knew it wasn't that. So I blame both MS and LL. 

[Arielle Popstar]

21 hours ago, Whirly Fizzle said:

BUG-139291 - Windows product key not suitable as unique machine key

Bug or flawed design?

Having been bit by that "bug" a few times (lost accounts) and complained to FS about it, I was informed it was intentionally designed that way and wasn't going to be changed. Correct me if I am wrong but I don't recall ever getting the problem on Singularity or other non-firestorm based viewers.

[Selene Gregoire]

2 minutes ago, Arielle Popstar said:

Bug or flawed design?

Having been bit by that "bug" a few times (lost accounts) and complained to FS about it, I was informed it was intentionally designed that way and wasn't going to be changed. Correct me if I am wrong but I don't recall ever getting the problem on Singularity or other non-firestorm based viewers.

It's been on the Jira for almost 2 years now and hasn't been assigned so I"d say they don't intend to fix it. And if that is the case, I'll have to start looking for another viewer to use because I'm not going to deal with this kind of crap every time MS updates Win10. Life is more than complicated enough with computers, cell phones and all the things that are supposed to make life easier and better but instead just makes life more complicated and difficult than necessary. Just more crap to have to keep up with and maintain.

[Whirly Fizzle]

4 hours ago, Arielle Popstar said:

Bug or flawed design?

Having been bit by that "bug" a few times (lost accounts) and complained to FS about it, I was informed it was intentionally designed that way and wasn't going to be changed. Correct me if I am wrong but I don't recall ever getting the problem on Singularity or other non-firestorm based viewers.

Technically not a bug.
But with Windows 10 changing the machine ID so frequently now, it's become an inconvenience.
This has been discussed several times within the Firestorm team about how it could be changed & still store your usernames & passwords securely.
However changing the way credentials are stored to a different method to that which the Linden viewer uses has everyone a bit nervous.
It's likely Firestorm won't change it till LL makes a change in their viewer.

It was one of the Firestorm developers that filed: BUG-139291 - Windows product key not suitable as unique machine key

[Whirly Fizzle]

4 hours ago, Selene Gregoire said:

It's been on the Jira for almost 2 years now and hasn't been assigned so I"d say they don't intend to fix it. And if that is the case, I'll have to start looking for another viewer to use because I'm not going to deal with this kind of crap every time MS updates Win10.

Your options will be limited.
As far as I'm aware no TPV based off the current LL viewer use a different method to store login credentials.
I suggest you try Singularity or CoolVL viewer.  It's possible those V1 based viewers use a different method, but I'm not sure.

I'm also not sure whether any other TPV stores multiple sets of usernames & passwords like Firestorm does.
The LL viewer certainly doesn't.  It will only remember your last used username & password.

[Gabriele Graves]

5 hours ago, Selene Gregoire said:

The only thing that changed on my pc was I had to update it from the 18xx to the 19xx because they are dropping support for 18xx. And I had been logged in after the ISP change so I knew it wasn't that. So I blame both MS and LL. 

Yes, how very annoying.  As you probably read elsewhere, I use a mix of Win7 (which I hope to retire soon) and Ubuntu Linux (which I hope to use exclusively soon) but I believe the principle around the key is the same, it is just the sources of data that build the key that are different.  If Windows 10 changes the value that is returned for one part of the key after an upgrade then you get same problem as me and have no idea what is going on.  I only figured out why mine was happening originally because I was disconnected from the internet and definitely needed to get that fixed anyway, once I did magically FS gave me back my login - pure accident really.

I cannot help but think that this is fundamentally the wrong approach to key management (not to mention security) for the viewer.  I would prefer the credentials being treated like a browser key chain or other credential store such as KeePass where you have to type in your passphrase to unlock the entire key store when the viewer starts.  This approach seems to be how most of the other applications that store credentials work.  Then we get control over when the passphrase changes and can even move the key store to other computers if we want to.  Relying on values that we have no control over and can arbitrarily change seems like it was a problem just waiting to happen in my opinion.

Edited August 10, 2019 by Gabriele Graves
typo and duplicate sentence that was left in after restructure.

[Fritigern Gothly]

20 minutes ago, Whirly Fizzle said:

As far as I'm aware no TPV based off the current LL viewer use a different method to store login credentials.

Regardless, a method to backup login info to an encrypted (password protected?) file would very welcome. Especially for cases where login info gets lost because the Windows key (or in the case of Linux, the network config) changes.

[Wulfie Reanimator]

24 minutes ago, Gabriele Graves said:

you have to type in your password to unlock the passwords

I heard you like passwords...

[Gabriele Graves]

14 minutes ago, Fritigern Gothly said:

Regardless, a method to backup login info to an encrypted (password protected?) file would very welcome. Especially for cases where login info gets lost because the Windows key (or in the case of Linux, the network config) changes.

Backing up would have to include the existing key as well or it wouldn't work when being restored.  If the current backup/restore feature was updated to ask the user for a passphrase and used this to encrypt the entire backup then the existing credential store decryption key could be stored securely as part of the backup as well.  We would then have one mechanism that worked as long as you had a backup and the passphrase.

[Gabriele Graves]

5 minutes ago, Wulfie Reanimator said:

I heard you like passwords...

Laugh all you want and I know it sounds amusing but this is standard for credential management applications.  What the viewer does is not standard.  What is really laughable is when all your credentials are lost due to something out of your control getting changed and you have no idea what or why.

Edited August 10, 2019 by Gabriele Graves

[Wulfie Reanimator]

Just now, Gabriele Graves said:

Laugh all you want and I know it sounds amusing but this is standard for credential management applications.  What the viewer does is not standard.  What is really laughable is when all your credentials are lost due to something out of your control gets changed and you have no idea what or why.

As someone who's been asking for 2-factor authentication for SL (a password for your password), it was a very joking post.

It's still amusing.

[Gabriele Graves]

3 minutes ago, Wulfie Reanimator said:

As someone who's been asking for 2-factor authentication for SL (a password for your password), it was a very joking post.

It's still amusing.

Agreed it is amusing and I would like to see 2-factor as an option as well.  Thank you for explaining your post a bit better, I am often terrible at discerning whether posts like these are just having fun or pouring scorn on an idea.

Edited August 10, 2019 by Gabriele Graves

[Fritigern Gothly]

45 minutes ago, Gabriele Graves said:

Backing up would have to include the existing key as well or it wouldn't work when being restored. 

Not necessarily.

• FS decrypt the credentials using the current key.
• FS then asks user to enter a passphrase which is used to re-encrypt the credentials in memory.
• FS creates a password-protected archive for an added layer of security. The password is unique to FS so that it's unlikely that a 3rd party has an easy time extracting the contents.

Upon import:

• FS extracts the contents of the archive to memory using the FS-specific password
• FS asks the user for their personal password
• If user password matches, the login credentials get decrypted in memory and restored to the credentials store which the new key/hash.

From the user's perspective, all they would have to do is provide a passphrase, hit "OK", and the credentials are backed up or restored.

I'm sure there are other, even more secure methods. But the point is that you do NOT need to supply the old key. After all, you want to restore the settings in case the key changes, so supplying the old key would not be very useful.

 

 

Edited August 10, 2019 by Fritigern Gothly

[Gabriele Graves]

3 minutes ago, Fritigern Gothly said:

Not necessarily.

• FS decrypt the credentials using the current key.
• FS then asks user to enter a passphrase which is used to re-encrypt the credentials in memory.
• FS creates a password-protected archive for an added layer of security. The password is unique to FS so that it's unlikely that a 3rd party has an easy time extracting the contents.

Upon import:

• FS extracts the contents of the archive to memory using the FS-specific password
• FS asks the user for their personal password
• If user password matches, the login credentials get decrypted in memory and restored to the credentials store which the new key/hash.

From the user's perspective, all they would have to do is provide a passphrase, hit "OK", and the credentials are backed up or restored.

I'm sure there are other, even more secure methods. But the point is that you do NOT need to supply the old key. After all, you want to restore the settings in case the key changes, so supplying the old key would not be very useful.

 

 

Yes, you are right that would avoid having to use the old key.  I think this is a pretty good idea overall and likely wouldn't have the same concerns that @Whirly Fizzle outlined with deviating from the LL implementation because they don't provide backup/restore.