Character protection

Was about to post this in the below thread, but you've just closed it

https://www.wilderssecurity.com/showthread.php?t=283229&page=3

Really !

In that case please can you give as full list of those so we can choose others, if we prefer

 

...as opposed to 'character assassination' > http://en.wikipedia.org/wiki/Character_assassination

 

Sorry about the thread confusion! SafeOnline will protect alphanumeric characters entered on the normal keyboard (0-9, A-Z irrespective of case). Other characters are sometimes protected but it depends on the context and language settings of the PC as many characters have different functions in different languages.

Hope that helps!

 

I assume that this is the same issue that I've previously reported where website password protection may not work if the password contains special characters, as most of mine do.

 

Well how about English, which characters Don't you protect ?

Sort of

 

The only non-protected characters are non-language characters in English (i.e. []\/$#!@)

Unless your password involves a lot of obfuscated swearing, you shouldn't have a problem

 

If we shouldn't use special characters with PSO, we'll need to make longer passwords, I guess.

 

Well, the rest of the password is protected - i.e. if your password is

secret123/password

the only thing that some keyloggers may be able to see is:

/

(and most websites wouldn't even accept that as a password anyway because of character restrictions)

 

Only That's quite a few, on my keyboard anyway

Is there a "Good" reason why you can't include everything, and/or is it a secret ?

Really ! i've never been so insulted for days

 

Non-alphanumeric characters are frequently used as "control" characters within the keyboard or as partial keystrokes in different languages. It opens up a massive area for incompatibilities by trying to protect every key without really providing much added value at all.

 

Hi Joe,

I agree that protection of alphanumeric input is what really matters from a key logging perspective. However, this still leaves an issue with SafeOnline's password protection. As you are aware, if a protected password contains non-alphanumeric characters, the protection doesn't work and the password can be entered into any website without SafeOnline alerting.

Given the difficulties of protecting non-alphanumeric characters due to the reasons you mention, a possible solution to the password protection issue might be to ignore any embedded non-alphanumeric characters when encrypting passwords, both when the value is initially stored and during the matching process whenever it is entered into a website. Whilst it would constitute partial matching rather than full matching, it should provide an effective solution and would certainly be an improvement on the current situation.

Regards

 

This is certainly a valid approach for the credential protection I'll see what we can do in terms of adding this into the current 3.0 SafeOnline but if we are unable to work around the character protection in 4.0, I definitely see this as being the way around it.