kwallet and safe password management

[gnomek]

Following my question about web browser's safety let me ask another question. Do you think it is safe to let a browser to remember passwords? I read that in case of attack attacker may get access to passwords if data stored by web browser are not cleaned. So every time I log somewhere I always clean/delete web browser data. Do I exaggerate or it is something recommended?

I guess web browsers use kwallet to store passwords, don't they? I didn't tried to let them remember, that's why I'm not sure.

I needed to set password to kwallet to empty space because I don't want to type password every time I check kmail. Would it mean a security danger in case of an attack? I don't think anyone can be interested in attacking me because I am not that interesting but I just want to know.

I think it would be great if kwallet could let passwords be used by web browsers and other applications without asking for passwords but still be protected by master password that would be activated when user logs into his/her account. That seems to me a convenient and reasonable solution. Is it possible to make such a setting?

[apachelogger]

Following my question about web browser's safety let me ask another question. Do you think it is safe to let a browser to remember passwords? I read that in case of attack attacker may get access to passwords if data stored by web browser are not cleaned. So every time I log somewhere I always clean/delete web browser data. Do I exaggerate or it is something recommended?

I guess web browsers use kwallet to store passwords, don't they? I didn't tried to let them remember, that's why I'm not sure.

Out of the top of my head there are two ways an attacker may use browser data.
1. They get access to the cookies and can use your cookies to pretend to a website that they are you. Logging out when done and not ticking the 'autlogin' box helps here.
2. They gain access in such a way that they can use functions/memory of your browser, in this case they may either read passwords from the browser memory (which is rather complicated) or (more likely) read them directly browser's password wallet. Former is really unlikely because most browser do not store passwords in memory for more than a fraction of a second (i.e. the time it takes to conduct the login). The latter is still unlikely if your browser is up-to-date, but not impossible, the only way to prevent this is to not store passwords at all.

As for whether it is recommended: if you are in a company dealing with sensitive data (bank for example) logging out and clearing your cookies and not saving passwords seems like a good idea, for a home user it certainly increases security. So, it really is up to you, if you can sleep better knowing that your browser data is very safe then you probably should take those measures.
My personal take is that if you save your password (which is unlikely to be accessed from a remote location) logging out and in when necessary is a relatively easy way to increase safety of your data. After all, next time you go the website the browser will fill in user and password automatically, so all you ever need to do is hit a login and a log

I needed to set password to kwallet to empty space because I don't want to type password every time I check kmail. Would it mean a security danger in case of an attack? I don't think anyone can be interested in attacking me because I am not that interesting but I just want to know.

Actually that used to be the default behavior for quite a while. I outline the general thoughts in https://bugs.launchpad.net/ubuntu/+s...s/+bug/1003398

Essentialy the important part of kwallet is the encryption of passwords (with kwallet deactivated most applications will store the passwords in plaintext in their configuration files!), the password just adds an additional layer of security for when someone gains physical access to the wallet file.

Again two cases.
1. The attacker penetrates the browser and can abuse the browser to send fake-queries for passwords (e.g. they exploit a bug in the browser so that they can send arbitrary password queries to the wallet). This attack is, as mentioned earlier, very unlikely. Plus the password protection of the wallet does not help you here at all because to kwallet it appears as if your browser, a probably trusted application, tries to request data.

2. If an attacker were to get direct access to the wallet file. In such a case the safety of that particular file is the least of your concerns as they can now at least read and edit *all* files in your home directory (perhaps even the entire system). Pulling this off requires a whole chain of security bugs in various components though (or physical access - i.e. they'd need to sit in front of your PC). In this particular case a password is useful. Beware though. Kwallet has a timeframe during which any appliciation can access the wallet (i.e. the wallet is considered open), this essentially means that someone who has direct access to an unlocked session can easily read passwords despite there being a password. Setting the timeout to 0 helps, but then you need to enter the password every time an app wants to read or write data.

Sorry if I got a bit verbose and technical here, but these things are better explained precisely. If you fail to follow a chain of thought I'll gladly try to make it simpler

I think it would be great if kwallet could let passwords be used by web browsers and other applications without asking for passwords but still be protected by master password that would be activated when user logs into his/her account. That seems to me a convenient and reasonable solution. Is it possible to make such a setting?

Not right now, though it has been considered for quite a while.
IT is what I mentioned in the last sentence of the bug report from above. Essentially you can make a password wallet aware of system authentications. This in particular means that once you logged in, the module that ensured that your login data is correct can tell kwallet "this user is properly authenticated, please give them access to the default wallet". That way your wallet can be protected by *any* password, as long as you successfully authenticated to the system as the user owning the wallet you get access to it.
Perhaps that will be reality in a not too distant future

[woodsmoke]

Hi gnomek

There is another way to approach this in that "if one does not go where grandma would not go then one has little reason to fear any kind of "attack" ".

I used to volunteer at a place called "Castle Cops" and what we did was remove, online, remotely, "stuff" from people's computers.

In almost one jillion percent of the cases, the person had "clicked" something that should not have been clicked and from there on it was all downhill.

As to e-mail, you can do an anti-virus check of each e-mail, but again, if you know the person from which it came then you should be able to trust it, but again, don't ever "click a forward"...

But again, with e-mail, Microsludge always defaulted to opening the first e-mail and people would click it and if it was an "attack" then things went downhill.

So, if you don't click attachments, that is were almost all of this stuff resides, then you will not have very much of a problem.

Basically, the stuff is not yet at the stage of being "self-aware" and being able to "do something" without you doing something first.

The VERY FIRST time that I got onto high speed cable internet a "male enhancement" product appeared magically in a big grey box. Even I knew this was suspicious behaviour and so hit the "x" button and it disappeared. I contacted the fellow who had helped me build the computer and he had no clue, I contacted the cable company and they.........LAUGHING while they said it....told me that it was a "no problem" TEST by Microsludge, to see if I would click it, MS was testing "the market" even way back then for their present antivirus and anti-malware program.

The cable people told me.....this is the honest truth, to use what THEY USED for a browser which was "MyIE2" which was the old IE 2 that microsith had dropped. and no baddies were making malware for it....and I used it for several years using Windblows until I got turned on to Linux.

So.....the basic upshot of this rambling post is that "if you don't click it then it won't be a problem".

But, if you are in a situation of having to "click stuff" then I'd very simply run it through an anti-virus application first.

In that way the malware/whatever won't get onto the machine in the first place and the passwords can then be thought of as keeping somebody off the machine that is physically in the area.

And, even that is shot with many holes. The college had us, up until a few years ago, change our passwords every semester, and they had a program that would check the "strength" of the password. One time I put in a totally random set of digits with two upper case letters one at the front and one at the end. The program said that it was a weak password. Did it again, samo, did it AGAIN...samo...

I then typed in the name of a well known enzyme.....such as Amylase and added "09" to it and the program said that it was a ONE HUNDRED PERCENT GREAT STRONG AS A STEEL SAFE password.

so again, if you don't click something you probably will not have a problem.

woodsmoke

woodsmoke

[SteveRiley]

2. If an attacker were to get direct access to the wallet file. In such a case the safety of that particular file is the least of your concerns as they can now at least read and edit *all* files in your home directory (perhaps even the entire system). Pulling this off requires a whole chain of security bugs in various components though (or physical access - i.e. they'd need to sit in front of your PC).

And it is for this reason that I am completely comfortable configuring my KWallet to be password-free, and why I also am comfortable recommending this to others.

During the portion of my career in which I was engaging in information security consulting and advisory work, I noticed that this important basic principle would frequently be forgotten. People who I would otherwise consider to be very smart would latch onto some goofily arcane and frequently exceptionally minor security control and cling to it as if it were a crucial element their very souls. The conversation would usually take this form:

BOB: "I want to implement FolfangaACL."
ME: "Why?"
BOB: "Because I { read about it in an airplane magazine | heard about it at a conference }."
ME: "What threats does FolfangaALC mitigate?"
BOB: "It stops Eve from plucking the lint out of the sysadmin's sister's belly button after 4:00 PM on Thursday when the bells ring."
SYSADMIN: "Hey, who told you about my sister and Eve...?"
ME: "Under what arrangement of circumstances will the sysadmin's sister's belly button present an attack surface?"
BOB: "Um, what?"
ME: "Here, look. You have several layers of defense already. For this attack scenario to succeed, the bad guy would first need to successfully penetrate several other layers, which actually is not trivial. I know this to be true because you hired me to put it all in place. But let's imagine he does. Guess what? It's too late! The system is already p0wn3d at this point, and there are far more interesting things for the bad guy to go after."
BOB: "But the { magazine | conference } said it's really important!"
ME: "It's really important for FolfangaACL to close this quarter profitably, and they're very good at finding suckers." [ME imagines "like you."]
ME: "The productivity cost to implement this control far outweighs any benefit you might gain. Your users will come after you with rocks and pitchforks. I'd advise you to forget about it."
BOB: "You really think so?"
ME: "I know so."
BOB: "Gosh, I'm glad you're here."
ME [silently]: I wish I weren't.