[opensuse] Have you done an update recently?
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. -- 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 2015-07-25 17:43, Anton Aylward wrote:
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.
True.
Lets not even think about updates to the cars and other IoT things! If we do we might get very, very frightened.
Well... I saw a video recently of hackers taking full control of a car, across Internet. And I mean full control, driving it into a ditch without the driver being able to do anything about it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 25/07/2015 17:43, Anton Aylward a écrit :
Lets not even think about updates to the cars and other IoT things! If we do we might get very, very frightened.
apart buying a Chrysler, did you see any dead body due to hacked android? may be we could work a bit more of an openSUSE Arm system, I would *love* to have openSUSE on my smartphone :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 25 Jul 2015 17:43, Anton Aylward <opensuse@...> 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. -- A secure smart-phone? Nokia 6010! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 07/25/2015 12:57 PM, Yamaban wrote:
I see your cars, and raise the "new" fad smart-home (i.e. easy to break in and manipulate)
IoT, IoT, Its off to work we go ... (refrain of the 21st century hackers) -- 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, Jul 25, 2015 at 12:57 PM, Yamaban <foerster@lisas.de> wrote:
On Sat, 25 Jul 2015 17:43, Anton Aylward <opensuse@...> 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 Sat, 25 Jul 2015 11:43:47 -0400 Anton Aylward <opensuse@antonaylward.com> 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.
What websites other than Google use two-factor authentication?
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.
Your mention of the subject starts to make me frightened.
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. I would have ranked "be suspicious of everything" as most important on that survey. As a newcomer to this mailing list, I apologize for any of its conventions that I may have ignored. -- 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 <opensuse@antonaylward.com> 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
-----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
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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-26 16:28, Andrew McGinnis wrote:
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.
Doable, I guess... :-? 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. 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW09J4ACgkQja8UbcUWM1yU+QD9ERkK++v54itx2S7H+Ht9dMZN odk8gYq9rpTOC6CtoawA/3kJJWCWigMGrgnZaY5B4dFlAoNwDH9mUmTVY1uakMmp =MSzp -----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." <robin.listas@telefonica.net> 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
On 07/26/2015 11:38 AM, Andrew McGinnis wrote:
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.
The fundamental problem is that fetchmail requires a cleartext rc file that contains cleartext passwords. It doesn't matter that when you're not logged in or the machine is down that the .fetchmailrc is actually on an encrypted partition. Having a symlink from /home/${USER}/.fetchmailrc to /encrypted/${USER}/fetchmailrc is fundamentally no different to having an encrypted /home or an encrypted /home/${USER}. The reason for this is that to be able to use it all you need to mount the volume unencrypted. The "running" system need the unencrypted view. 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! This is the basis of a novel by John Sandford http://www.johnsandford.org/kidd04.html 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. 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. -- 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
-----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 July 26, 2015 11:38:26 AM EDT, Andrew McGinnis <mcginnisandrew4@gmail.com> wrote:
On Sun, 26 Jul 2015 16:54:22 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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.
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. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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)
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. All .fetchmailrc password encryption would have done is give a false sense of security to people who don't think very hard. The general rule here is: 17. A security system is only as secure as its secret. Beware of pseudo-secrets. </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. Maybe you should be using getmail. After all, fetchmail has been beset by other security problems that indicate a lack of understanding of how to code in the mechanisms. http://www.fetchmail.info/security.html http://pyropus.ca/software/getmail/faq.html#faq-about-why I've given up on fetchmail and now use thunderbird's TLS. What? oh, right, that's another set of problems... Round and round we go ... -- 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 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
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. 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. If you have /home/${USER} encrypted then you need to have it unencrypted to be able to log in and as long as you are logged in it there in the clear. There's the old saying about the cryptanalytic properties of a blunt, heavy objects. Usually they are applied to finding keys. In the Sandford novel it was applied to the user while he was logged in. The thief only had to keep the laptop powered up. So long as it was powered up and he never logged out he had access to the "encrypted" partition. Encrypting individual files is another matter. But then there's the matter of convenience. You can PGP encrypt your files but the program will remember you passphrase for a few minutes as a convenience. Well, you find its doesn't remember it for long enough so you alter that parameter, 15 min, 30 min, one hour, all day. Always a trade off: security vs convenience. Convenience usually wins. -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. 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. There is no access to the running session unless he knows the user password, and no access via network without password, unless he knows of a suitable security hole.
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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW2GdcACgkQja8UbcUWM1w7gQEAiaEdmBijiHF4LYQJuK7PvK4Q 2TFKgkJ3PZTnZKUEum4A/iPVjNYxBPIXaKCRPJzsU4yOY4paawfdofMYu42rL7lm =YJGW -----END PGP SIGNATURE----- -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-27 14:10, Anton Aylward wrote:
On 07/27/2015 07:45 AM, Carlos E. R. wrote:
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?
Because that's what happens in real life. That's how I use my laptop.
In the novel, the real user was wheelchair bound. He was knocked unconscious (and killed) while using the machine.
Well, that's a percent of cases. They can also point at me with a gun and politely ask for my password and bank pin. Doesn't void my use pattern of my computer at all...
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. A process ram can be read by another process with sufficient privileges. Read the GPG docs.
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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW2LjkACgkQja8UbcUWM1wB0gD+NT1LsO3WIFDW4gvuyrMws2za eL/dPvBgOwnoFytAuLUBAJRaFxs2q37jBTrx2CuqGKPyzK7r4I70mYcjQl3f4r+v =cBKd -----END PGP SIGNATURE----- -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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.
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.
Maybe not, but I want to avoid the issue of a thief having easy access to my email password as a benefit. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW2OXEACgkQja8UbcUWM1zQVQD/RFQGHQwXUaVT7Sjnif+NrVSc 4v9A1ZOrbhJF6n7a4iwBAJ+GaRHVeCIt0rf8PZTaGw+Fd1LWczHDzcIJcPsd2pao =XMjv -----END PGP SIGNATURE----- -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-27 16:27, Anton Aylward wrote:
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.
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. Recently GPG pops a big warning about being hijacked by some other desktop service, and refusing to run, I think. My script could easily remove the tmp file on exit, or do it later via an "at" job. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW2RSIACgkQja8UbcUWM1ztQgD/cOqNHTl7MlxrhqzilU5kl18O wRTS9+Nm6vzTUlH8VWQBAIhafyi+PtLotyEuD1tQulY7nacd5wLK9WsKMtocpqKo =xjzH -----END PGP SIGNATURE----- -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-27 17:15, Anton Aylward wrote:
On 07/27/2015 10:50 AM, Carlos E. R. wrote:
Please do not talk about the way YOU have configured YOUR system as if they were universal constraints.
I didn't. Besides that, you are not aware of recent agent hijack issue. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW2TpEACgkQja8UbcUWM1xswwD/WxilHpHNR6NjM9E+VopPwSSf YmrtVakZt9xY57ZX5VQBAJsd3mdWnVBkafOFR9UGA7UwA4D5lvFyYL1Hl/I/L224 =T8TZ -----END PGP SIGNATURE----- -- 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 <opensuse@antonaylward.com> 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
participants (9)
-
Andrew McGinnis -
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Chris Murphy -
Greg Freemyer -
greg.freemyer＠gmail.com
-
jdd -
Yamaban