On 2015-07-25 18:57, Yamaban wrote:

Even more ugly: Power-plants, Power-lines, Fresh-water plants, Waste-water treatment plants, etc -- all easy to reach and break in (electronically) just because "security" is treated as "obscurity".

About year 2000, I found out that phone exchanges, handling, say, a hundred thousand customers, were reachable by modem. Just phone a number, and you were in, no login, no password. I could shut the entire thing down! Of course, you needed to know the commands to use, but possibly by trying you could do damage. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Sat, Jul 25, 2015 at 12:57 PM, Yamaban wrote:

On Sat, 25 Jul 2015 17:43, Anton Aylward wrote:

...

http://www.geek.com/apps/google-compares-security-experts-to-the-rest-of-us-...

Yes I use a unique password generator and I get VERY ANNOYED at sites that a) don't differentiate between UC and LC b) don't permit non alpha characters, especially spaces c) won't let me use password longer than 15 characters or truncate them down to 8 characters

Yes I have a password manager.

Yes I update daily.

Sadly few sites, not least of all my banks, use two-factor authentication. The best of them use what amounts to a 'double password' scheme.

All that being said ....

While I update the apps on my phone and tablet, there seems to be no updates to the kernel/os other than buying a new phone or rooting it and installing a 3rd party ROM - which may lack functionality or have other problems.

Lets not even think about updates to the cars and other IoT things! If we do we might get very, very frightened.

I see your cars, and raise the "new" fad smart-home (i.e. easy to break in and manipulate)

Even more ugly: Power-plants, Power-lines, Fresh-water plants, Waste-water treatment plants, etc -- all easy to reach and break in (electronically) just because "security" is treated as "obscurity".

A nice part of my daily work consists in reducing such possible attack areas. In some cases by pulling the plug between internal network and internet because: "the internet is safe, we do not need any firewalls".

"Passwords? -- What passwords??" and the ever famous: "Encrypted communication, what's that?" are daily fun for me.

"Stuxnet" has never happened for these guys, and they are Managers.

I avoid having a mobile if ever possible.

- Yamaban.

Then you'll appreciate this: I went with a security analyst to review a construction firm that wanted to get top secret clearance so they could work on government facilities. My task was unrelated to the review, but I was going to need Administrator access to the server. We arrived at the same time. The receptionist told me my contact was unavailable but she told me where the server was and the that the admin password was on a sticky on the screen. The computer turned out NOT to be in a physically secure area so anyone in the company could access it. And any of them could have seen (recorded) the admin password. The guy doing the security review found that very interesting and took a few pictures. Needless to say, they failed the security review pretty badly. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/25/2015 10:03 PM, Andrew McGinnis wrote:

On Sat, 25 Jul 2015 11:43:47 -0400 Anton Aylward wrote:

...

Sadly few sites, not least of all my banks, use two-factor authentication. The best of them use what amounts to a 'double password' scheme.

What websites other than Google use two-factor authentication?

As I implied, quite a few bank. or their brokerage arms. In some countries and not others. It make sense to have financial transactions more aggressively secured. Perhaps we also need to force some classes of personal financial transactions to require personal certificates as well so as to have two way authentication, just as banks do when talking to each other for transfers.

...

Lets not even think about updates to the cars and other IoT things! If we do we might get very, very frightened.

Your mention of the subject starts to make me frightened.

Good. The whole IoT thing, not just the house but all the other things we are putting on the net for remote access; monitoring and control - is a vendor's feeding frenzy that is showing little concern for any aspect of security, never mind simple authentication.

Reading through the paper, I noticed that using HTTPS is considered an advisable security strategy. While I don't doubt that sending passwords via SSL is more secure than sending them as unencrypted plain text, I sometimes question the security of SSL. My understanding of the protocol is that a server sends its certificate to the client unencrypted to initiate the connection. If this is right, then an SSL certificate can be intercepted, and the encrypted internet traffic can be decrypted.

Its not that simple. The 'key exchange' problem existed for centuries. The Diffie & Hellman key Exchange system solved that https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange http://security.stackexchange.com/questions/45963/diffie-hellman-key-exchang... See also "Authenticated Diffie-Hellman" In practice, its used to set a session key which is then used to create a short lived key that is discarded after N packets, and another key generated by means of the session key. The public certificate is a convenience; strictly speaking that is RSA. There are other ways of doing that part of it. Strictly speaking you don't need a certificate to use SSL/TLS (see PSK, Kerberos and even anonymous cipher suites). Also: check the difference between SSL, TLS and HTTPS HTTPS is application layer protocol.

I would have ranked "be suspicious of everything" as most important on that survey.

Marcus Ranum said: One person's "paranoia" is another person's "engineering redundancy."

As a newcomer to this mailing list, I apologize for any of its conventions that I may have ignored.

Trim, Trim, Trim! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Have you thought about encrypting the file itself (see https://www.openssl.org/docs/apps/enc.html)? You would probably have to decrypt the file each time you start fetchmail, and remove it before you log off, but openSSL has a command line interface; just write a script to do this when fetchmail starts. On Sun, 26 Jul 2015 15:37:22 +0200 "Carlos E. R." wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-07-26 05:34, Anton Aylward wrote:

...

...

What websites other than Google use two-factor authentication?

As I implied, quite a few bank. or their brokerage arms. In some countries and not others. It make sense to have financial transactions more aggressively secured. Perhaps we also need to force some classes of personal financial transactions to require personal certificates as well so as to have two way authentication, just as banks do when talking to each other for transfers.

As I was going to sleep yesterday, I thought of an issue: email passwords as stored by fetchmail.

Fetchmail stores the passwords in a plain text file, which is only protected by the Linux user password while the system is running. A laptop can be stolen and the passwords simple read from the disk.

Some people may think that it is just email. But email is often used as one of the factors in authentication to many sites. In many it is used as a method to send passwords when lost. Thus securing the email password is crucial.

I can only think of symlinking .fetchmail to an encrypted partition. Another way?

- -- Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlW04pIACgkQja8UbcUWM1zbaQD/Vznz8pgBvpjLLbIhH7wyEWoL 8LxXdYAvoROV0Apt2aoA/R80aGVQy63ViVBnrZajoHKpalIRQGqdcewZm3ua+owu =us+b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 26 Jul 2015 16:54:22 +0200 "Carlos E. R." wrote:

Meanwhile, I have stored the file in my encrypted partition, with a symlink to home.

But this could be a big security failure on fetchmail. Thunderbird safely (I hope) secures passwords under a master password. Unless I missed something in the docs.

Not sure about Thunderbird; I haven't used it in a long time.

Something like what you suggest would do it, I guess. The file could be stored in tmpfs, so it is automatically destroyed on power down, or by a cron job if not accessed in some time.

There's plenty of options, I'm sure. If you can define the password file for fetchmail, these are probably better solutions than mine. I'm not familiar with fetchmail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-26 18:00, Anton Aylward wrote:

The protection that encrypting a drive or partition offers is useful if the laptop is stolen when powered down. If its stolen when powered up then the thief just has to make sure it never powers down!

He also needs to be able to login, or that there is an open sesion, unlocked. which reminds me that the screen saver was removed from kde (?) because it could be killed, and then gain access to the session.

This is the basis of a novel by John Sandford http://www.johnsandford.org/kidd04.html

Mmm :-)

A better approach is to have the password fields encrypted and code in the 'fetch' program (whatever it may be) that can handle that encryption. This may be a dedicated filed in a sqlite database or a record in a KDE wallet or Gnome keychain.

The problem is that the author of fetchmail made a decision not to have those fields encrypted and not to have the code to handle encrypted field in the body of the program.

Yes, it seems so.

I say "better" above because there are still modes where the password could be snooped. That's why you should use TLS. But that's another matter. Ridiculously, Eric Raymond thought it was OK to have the crypto code to handle TLS but not encrypted fields.

Mmmm... So I will have to hack a script. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW1lZUACgkQja8UbcUWM1w7+gD8ClF/Ez2RuIfwhipZSfEpmFKQ /7z9DSj2p+P/QeTzN5QA/jm7iQL+KJ0H1FqiKSl5MlFPbm6npFbCSTJ4AG8fwzdZ =6BuM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-07-27 02:54, greg.freemyer@gmail.com wrote:

LaZagne from the security:forensics repo has a goal of showing you what easy to retrieve passwords you have.

https://build.opensuse.org/package/show/security:forensics/LaZagne

Certainly anything it finds is not well protected, but it may miss some obvious things.

I don't recall if it retrieves fetchmail or thunderbird passwords.

There is no point of trying with fetchmail, as they are stored in plain text files, in clear text. Just read them! How safe is thunderbird/firefox storing them, that is interesting to know, though. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-26 17:35, Anton Aylward wrote:

On 07/26/2015 09:37 AM, Carlos E. R. wrote: .

...

Fetchmail stores the passwords in a plain text file, which is only protected by the Linux user password while the system is running. A laptop can be stolen and the passwords simple read from the disk.

The 'inventor' of fetchmail says <quote src="http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s09.html">

Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn't be able to casually see them.

I didn't do it, because this doesn't actually add protection. Anyone who's acquired permissions to read your rc file will be able to run fetchmail as you anyway—and if it's your password they're after, they'd be able to rip the necessary decoder out of the fetchmail code itself to get it.

Well, that's true. You need a mechanism that asks the user to type a master password to decrypt the stored passwords.

</quote>

Well, yes, having .fetchmail on a encrypted partition is a second order pseudo-secret. When you are logged in and active that partition is "unlocked" so you can use it.

Not exactly, because you need to enter a password to open the partition at some point. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW1lp0ACgkQja8UbcUWM1zemQD/TMyyX+qpnA/DZDAp+TuI+H7b yemw/RJetwEmTpfr3YIA/1Vaf8zkQn/aw5UwmTFUlo19WL5p+zZeuzotPHOeP9jT =l5qS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

With ext4 supporting per directory encryption, it's possible to have better granularity along with convenience. Hopefully this work is adaptable for other file systems. In the meantime, particularly sensitive material needs to go in a separately encrypted image file, and maybe somehow put it on a timer for umount, then cryptsetup close. Systemd supports timers, but maybe not yet an inactivity based one. --- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/27/2015 07:45 AM, Carlos E. R. wrote:

On 2015-07-27 05:05, Anton Aylward wrote:

...

On 07/26/2015 10:25 PM, Carlos E. R. wrote:

...

...

...

Well, yes, having .fetchmail on a encrypted partition is a second order pseudo-secret. When you are logged in and active that partition is "unlocked" so you can use it. Not exactly, because you need to enter a password to open the partition at some point.

...

Once again I refer you to the John Sandford novel. The laptop was stolen while the main user was logged in and had opened up the encrypted user partition.

Well, even if I got that novel, it would go to the end of my reading queue, so I would not read it till a month. You will have to explain how he does it.

Assume the laptop is running, with the encrypted spaces open, yes.

Yes, the real user is using it.

When a laptop is stolen it is normally suspended/hibernated, and inside a bag or on a table, while the owner is somewhere else. Meaning that the screen is locked, so the thieve can not access the running system.

Why are you making that assumption? In the novel, the real user was wheelchair bound. He was knocked unconscious (and killed) while using the machine. While you are I might walk away from the table to schmooze, lunch or micturate, he didn't have that option, so it seems he didn't have a screen saver. So long as the machine was powered up it was logged in and the encrypted partition was open. Now you or I might do things differently, but that's the novel.

...

UNLESS you have some kind of scripting that says 'open encrypted partition using keyword; extract passwords; close encrypted partition; forget keyword' then all is lost.

Actually that is what I intend to do. Have an encrypted file, prompt for a password, and create a clear text copy of the file in tmpfs, so that it is automatically lost on power down or reboot.

Personally I think that the idea of having a cleartext version available anywhere is a bad idea. If it matters that much there should be no cleartext version anywhere except in memory. And possibly not even that. The application should read the RC file and the RC file should have the password fields encrypted. The application should decode them in its internal memory, use them, and the ** overwrite that internal memory ** so that even memory scrapers will have a limited window of opportunity. Of course all this is really a pole of crap, isn't it? You're not using those IMAP/POP passwords anywhere else are you? You are reading (or at least rendering) the email as clear text. Its not that we couldn't have a email system that makes use of cryptographic signatures as ID, diffie-hellman exchange to generate unique, one time passwords of arbitrary bit length (you want 4096 bits, sure, no problem!). Such schemes have been proposed and even implemented. But WHY? The whole point of mass mail or mailing lists like this is that its in the KISS Class. You want secure point-to-point email between individuals or small groups? it comes down to key management. Yes do it over SMTP, its ubiquitous. Try PGP for starters. At least it keeps external keys encrypted. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/27/2015 09:12 AM, Carlos E. R. wrote:

...

...

Personally I think that the idea of having a cleartext version available anywhere is a bad idea. If it matters that much there should be no cleartext version anywhere except in memory.

And that's where it will be. tmpfs is memory.

No. a tmpfs is part of the file system.

A process ram can be read by another process with sufficient privileges. Read the GPG docs.

This is where Chris would start talking about AppArmour and SELinux as containment measures. We all know that unless you take additional measures 'root' is all powerful and many sites hand out root access like candy. That and there are many ways to get root access or trojan a system. UNIX/Linux is not immune. Its not that it can't be strapped down tight. What do you think all those Linux servers on wall Street handing million dollar transactions are about? But that level of knowledge and diligence and the constraints they operate under are different from out home based workstations. You can bet such organizations handle email in a very different way and have dedicated machines and pathways for it.

...

...

Of course all this is really a pole of crap, isn't it? You're not using those IMAP/POP passwords anywhere else are you?

No, but an attacker with access to a person email can request the password for many other services to be reset. A link is sent to the mail, click, change password. Even to banks.

That's my issue.

You don't have to have access to my email to request a password reset. A good system will send me a notification and a URL as a result of request. Perhaps that can be MitM'd and I won't see it and you can act on it. But if you have that level of access you can do many other things. its sort of like the inconsistencies about the access control in that movie, what was it 'ex machina', I think. if you can MitM my communications why waste time resetting some of my web accounts. A bad reset system won't mail me back with a URL; it will just let you do the reset. There are a few of those around. Nobody says that web site developers put security first and foremost. The real problem here is quite simple: PASSWORDS. What? Oh Sorry, the real problem is that the users prefer dancing pigs, as Bruce Schneier says. Convenience trumps security. You could have a PGP-like authentication which forgets the long, certificate based two-factor authentication and makes you re-enter it every few minutes. But you'd go crazy. You'd never get any work done. Try, for example, having a password protected screen saver that come in after 2 seconds of inactivity ... that level of re-authentication. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/27/2015 10:00 AM, Carlos E. R. wrote:

On 2015-07-27 15:46, Anton Aylward wrote:

...

On 07/27/2015 09:12 AM, Carlos E. R. wrote:

...

...

...

Personally I think that the idea of having a cleartext version available anywhere is a bad idea. If it matters that much there should be no cleartext version anywhere except in memory.

...

...

And that's where it will be. tmpfs is memory.

...

No. a tmpfs is part of the file system.

Yes, but in memory. It is memory. :-)

And, in Linux, a process memory can be accessed as a file under /proc, I believe, so memory is also filesystem :-p

What matters is that the clear text password is not on disk.

*sigh* if you log out each day (at least) and shut down (each day at least)[1] so that the window is small then not having the clear text in persistent storage at least limits the modes of attack. But if you are going to bring /proc/<id>/mem into it and require root access then there are many much simpler methods of attack than reading memory. [1] as in when you break for coffee, break to answer the phone, break to go to a meeting, break to go to lunch, break to go micturate, use some other application and so shut down email[]2] [2] All of which gets very iffy if you use a tablet or phone or pretty much anything except a desktop PC. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/27/2015 10:50 AM, Carlos E. R. wrote:

Well, the PGP password is cached for a long time. It can be for the entire session, which can last weeks. And on some desktops, it is only protected by the user password.

All that is configurable; back to RTFM. I have my passphrase cached for 600 seconds ONLY. That, as far as I can tell, is the default with gpg2. I'm not saying there aren't implementations which allow short paraphrases or have session as the default settings; but the GPG/GPG-agent way of using GP on Linux Desktop is more reasonable. The "Enigmail" plugin for Thunderbird on Linux makes use of GPG & GPG agent. I see you are using Thunderbird/38.1.0. and GnuPG v2.0.22 so if you have a session time-out on your passphrase you must have explicitly set that. Please do not talk about the way YOU have configured YOUR system as if they were universal constraints. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 25 Jul 2015 23:34:11 -0400 Anton Aylward wrote:

...

Reading through the paper, I noticed that using HTTPS is considered an advisable security strategy. While I don't doubt that sending passwords via SSL is more secure than sending them as unencrypted plain text, I sometimes question the security of SSL. My understanding of the protocol is that a server sends its certificate to the client unencrypted to initiate the connection. If this is right, then an SSL certificate can be intercepted, and the encrypted internet traffic can be decrypted.

Its not that simple. The 'key exchange' problem existed for centuries. The Diffie & Hellman key Exchange system solved that https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange http://security.stackexchange.com/questions/45963/diffie-hellman-key-exchang...

See also "Authenticated Diffie-Hellman"

In practice, its used to set a session key which is then used to create a short lived key that is discarded after N packets, and another key generated by means of the session key.

The public certificate is a convenience; strictly speaking that is RSA. There are other ways of doing that part of it. Strictly speaking you don't need a certificate to use SSL/TLS (see PSK, Kerberos and even anonymous cipher suites).

Also: check the difference between SSL, TLS and HTTPS

HTTPS is application layer protocol.

I suspected that it wasn't that simple. Thanks for sharing this information. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org