Skip to main content
To Customer Support To Customer Support
When I want to login to https://my.webrootanywhere.com/default.aspx I have to enter a password and after that I am asked to confirm the login ("Please enter the X and Y characters of your Security Code (case sensitive)).

 

This information (full security code!) can only be saved in plain text on your servers. Isn't that a very high security risk?

 

See https://forums.lastpass.com/viewtopic.php?f=13&t=129585
That is a good point - let me ask around and get more info.  I know we're in the process of changing that and looking into two-factor authentication as well.
THanks Nic, I wasn't able to answer that question?!:S
Hi webrootuser

 

Would be interested to know how you know that "...This information (full security code!) can only be saved in plain text on your servers."?  It is not that I doubt you but rather I cannot see why that information along with other key user informastion would not be encrypted, especially given the business that Webroot are in?

 

Just curious.

 

Regards

 

 

Baldrick
@ wrote:

Hi webrootuser

 

Would be interested to know how you know that "...This information (full security code!) can only be saved in plain text on your servers."?  It is not that I doubt you but rather I cannot see why that information along with other key user informastion would not be encrypted, especially given the business that Webroot are in?

 

Just curious.

 

Regards

 

 

Baldrick

He's making the point that since you are only entering individual digits from the code, there's no hash function that is going to work.  That means we have to have the security code in plaintext for comparison - it isn't a technical issue but a cryptographic one.  Since we do have a regular password then that can be hashed as usual, that still offers traditional single-factor authentication.  But if the security code is stored in plaintext then it could be stolen if our database were to be compromised.  While this wouldn't necessarily get you into someone's portal by itself, people often re-use PINs across multiple functions so it could compromise other services.
Hi Nic

 

I appreciate that but do not agree that just because one enters individual digits then one has to have the security code in plaintext for comparison.  In some systems I have run into the plain text characters are encrypted and then compared to the encrypted whole code, which is encrypted character by character...but still encrypted...and as long as the key used is the same for both the encryption of the individual characters entered by the user and the individual part of the whole code...no issue, and anyone looking at the whole code cannot discerne it without the key.

 

But obvioulsy I do not know what or Webroot do what they do or do not do...just saying that I find it surprising that Webroot would not encrypt, and was wondering as rto how this 'lack of encryption' had been identified by a user.

 

As I said...forever curious...thats me...;)

 

Regards

 

 

Baldrick
Yeah, I guess you could encrypt character by character, but it seems like the search space would be fairly limited.  For alphanumeric you'd be limited to 26+10 (or maybe a bit more in you included special characters).  I would think that would make the hashes trivial to break, but I'm only a cryptographic dabbler and not an expert 🙂  I've put out the word internally for some feedback and we'll see what Grayson and others have to say.
Cool, Nic.

 

It is an interesting topic and I, like you, am a dabbler/interested party rather than an expert...so it will be good to get the professional lowdown on this.

 

Thanks to webrootuser for raising the topic. :D

 

Regards

 

 

 

Baldrick
Hello...just want to say I'm curious to what Grayson saids...looking forward to more information all around. As it was interesting that Webrootuser posted this...good stuff!



Awaiting....:)
"He's making the point that since you are only entering individual digits from the code, there's no hash function that is going to work.  That means we have to have the security code in plaintext for comparison..."

 

Exactly, that's what I meant. 
So I have confirmed with the folks here that we store the secure word in plaintext.  That means don't re-use the secure word anywhere else, as the password or PIN to other services.  Still talking over the deeper security implications and will update when I have more.
Ok great. Will have to change one pass word since I'm one f those people who use same one twice..bad I know...Thank you!!
It's always good to know something more about it ;)

Thanks Nic!

 
Well, I for one am gobsmacked...who would have thought it especially since there is no need to store the code in plain text, and therefore of a security company. :(

 

Oh, well...apology humbly offered to webrootuser.

 

Baldrick :$
@ wrote:

Well, I for one am gobsmacked...who would have thought it especially since there is no need to store the code in plain text, and therefore of a security company. :(

 

Oh, well...apology humbly offered to webrootuser.

 

Baldrick :$

Doing some research I did find some alternate suggestions, such as symmetrical encryption or this idea based on an algorithm called Shamir's Shared Secret.  I've passed that along to the folks here for consideration.  The only practical issue with storing the secure word is if it is used elsewhere, like Sherry found she was doing.  Still, would be good to set a better example, as you say @ :)  

 

Since we have a regular salted and hashed password before the secure word, the portal access is still secure.  The partial password portion using the secure word can help against situations where your data might be sniffed via a man-in-the-middle attack on an unsecure network, or someone installing a keylogger (although you'd hope anyone logging into the portal would do it from a machine that has WSA on it to prevent that).
Cheers, Nic

 

That is interesting, especially the Shamir's Shared Secret algorithm...had not come across that one before...all very interesting.

 

Regards

 

 

Baldrick

Reply


Terms & Conditions