Re: Has there been a change in US banking regulations recently?
On Fri, Aug 13, 2010 at 09:32:57AM -0700, Jeff Simmons wrote:
It wouldn't surprise me if there's been some blowback from the
adoption of PCI-DSS (Payment Card Industry Data Security
Standards). As someone who has had to help several small to medium
size businesses comply with these 'voluntary' standards, the irony
of the fact that the big banks that require them often aren't in
compliance themselves hasn't escaped my notice.
In the past month, we've had several customers at work suddenly
insist that we make modifications to their firewalls and/or load
balancers to redirect *all* incoming HTTP traffic to HTTPS (which of
course isn't always entirely sane to do on proxying devices, but
they apparently don't trust their server admins to maintain an HTTP
redirect). Most of them cited requirements from their PCI-DSS
auditors. One apparently was outright told that their redirects were
a security problem because they presented an open socket on port
80, and they needed to be refusing all HTTP to their servers at the
firewall. I think we gave them sufficient wording to convince their
auditor that blocking access to the redirect itself wasn't going to
do anyone any good.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What EV certs are good for
On Tue, Jan 27, 2009 at 09:04:45AM -0500, Jerry Leichter wrote:
[...]
It might be useful to put together a special-purpose HTTPS client
which would initiate a connection and tell you about the cert
returned, then exit.
[...]
I often use this (though there's probably an easier way)...
echo|openssl s_client -connect www.example.com:https|openssl x509 -text
Quick and dirty, but gets the job done.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Ransomware
On Tue, Jun 10, 2008 at 11:41:56PM +0100, Dave Howe wrote:
The key size would imply PKI; that being true, then the ransom may
be for a session key (specific per machine) rather than the
master key it is unwrapped with.
Per the computerworld.com article:
Kaspersky has the public key in hand ? it is included in the
Trojan's code ? but not the associated private key necessary to
unlock the encrypted files.
http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9094818
This would seem to imply they already verified the public key was
constant in the trojan and didn't differ between machines (or that
I'm giving Kaspersky's team too much credit with my assumptions).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ransomware
On Wed, Jun 11, 2008 at 11:53:54AM -0400, Leichter, Jerry wrote:
Returning to the point of the earlier question - why doesn't someone
pay the ransom once and then use the key to decrypt everyone's files:
Assuming, as seems reasonable, that there is a session key created
per machine and then encrypted with the public key, what you'd get
for your ransom money is the decryption of that one session key.
Enough to decrypt your files, not useful on any other machine.
There's absolutely no reason the blackmailer should ever reveal the
actual private key to anyone (short of rubber-hose treatment of some
sort).
Maybe I missed it in one of the articles, but was it stated that the
blackmailer did reveal a private key? Couldn't they simply request
the encrypted data and return the decrypted version?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Wed, May 28, 2008 at 10:34:53AM +0200, Philipp Gühring wrote:
it is imperative that wasteful reads of this pseudo-device be
avoided at all costs.
Yes. Still, some people are using fopen/fread to access
/dev/random, which does pre-fetching on most implementations I
saw, so using open/read is preferred for using /dev/random.
Implementations can be rather easily checked with strace.
Oh, agreed wholeheartedly. I simply meant that *wasteful*
(gratuitous) reads of /dev/random should be avoided. Justifiable,
conservative reads of /dev/random are, of course, why it exists in
the first place!
And fopen/fread is definitely a bad idea in this case for the
reasons you point out. In general, anything which prefetches
potentially excess data in a read from /dev/random is destructive to
the entropy pool.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Sat, Feb 23, 2008 at 05:09:29AM +1300, Peter Gutmann wrote:
There were commercial products that did this available some years
ago, they hooked into the Windows auth using a custom GINA DLL
(GINA = the Windows extensible login/authentication mechanism,
think PAM for Windows) and locked the machine when you moved away
from it. They failed in the marketplace, there was no interest in
them from users (or at least several of them failed, some may
still be around).
[...]
Saw an interesting free software example of this the other day (not
for Windows, of course) using loss of signal from a particular
bluetooth device (mobile phone, et cetera) to lock your machine or
run other designated commands:
http://sourceforge.net/projects/blueproximity/
It also supports *unlocking* on approach, but that's a bad idea
unless they can start providing a client to run on the token
device (maybe using asymmetric key crypto to sign and verify a
challenge string instead of just looking for the device's BT
address).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Mon, Jan 28, 2008 at 03:56:11PM -0700, John Denker wrote:
[...]
I don't think it is very common; I get only five hits from
http://www.google.com/search?q=two-person-login
[...]
Try searching for secret splitting instead.
From the foregoing, you might conclude that the two-person login
system is worthless security theater ... but harmless security
theater, and therefore not worth worrying about either way.
[...]
So now I throw it open for discussion. Is there any significant
value in two-person login? That is, can you identify any threat
that is alleviated by two-person login, that is not more wisely
alleviated in some other way?
[...]
I don't think it's security theater at all, as long as established
procedure backs up this implementation in a sane way. For example,
in my professional life, we use this technique for commiting changes
to high-priority systems. Procedure is that two security admins
(each with half of a cryptographic key) collaborate on updates. Sure
there's still the risk that one is nefarious and will socially
engineer a back door in while his/her counterpart is watching, but
that is not so much the risk we are attempting to thwart. The real
goal is to reinforce policy which requires collaboration between
administrators for major changes to these important systems.
Technology can't effectively *force* procedure (ingenious people
will always find a way around the better mousetrap), but it can help
remind them how they are expected to interact with systems.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Tue, Jan 29, 2008 at 03:37:26PM -0600, Nicolas Williams wrote:
I think you missed John's point, which is that two-person *login*
says *nothing* about what happens once logged in -- logging in
enables arbitrary subsequent transactions that may not require two
people to acquiesce.
Certainly, but then neither does a one-person login (people can
always log into a system and then walk away to get a cup of coffee,
for that matter).
What if one of the persons leaves the other alone to do whatever they
wish with the system? Or are the two persons chained to each other?
(And even then, there's no guarantee that they are both conscious at the
same time, that no third person shows up and knocks them out *after*
they've logged in, ...)
Of course, this is common sense. These are human problems which I do
not think can *ever* be solved through application of cryptography.
As I said, requiring two sets of credentials can act as a reminder
to work together, nothing more. There's no way that I know of to
force a person to pay attention, or for that matter do anything they
do not wish to do.
When you force two people to participate on a *per-transaction* basis
then you probably get both of them to pay attention, though such schemes
might not scale to thousands, or even hundreds of transactions per-team,
per-day.
Agreed--it would be nonsense to dream otherwise. My only point was
to suggest that there are some circumstances in which a system like
this can be helpful/useful, which was one of the questions John
asked. It is simply necessary that when employing such a system, you
be aware of what problems it actually *can* solve, and what problems
it cannot. I have no doubt that some people attempt to employ these
sorts of solutions in ways which they are indeed inapplicable (or
put too much faith in the false sense of security it gives them),
possibly at the urging of their snake oil vendors. This is why
scrutiny of the *application* of a technology is at least as
important as scrutiny of the technology itself.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: virtualization as a threat to RNG
On Tue, Mar 20, 2007 at 08:14:26PM -0400, Dan Geer wrote:
Quoting from a discussion of threat posed by software virtualization as
found in Symantec's ISTR:xi, released today:
The second type of threat that Symantec believes could emerge is
related to the impact that softwarevirtualized computers may have on
random number generators that are used inside guest operating systems
on virtual machines.
[...]
I will note that, on User-Mode Linux at least, a good approach seems
to be using the UML kernel option/driver to broker access to the host's
entropy via a faked hardware RNG. The down-side is that your host may
well need a boosted entropy source, if you have a lot of guests
using this feature. I'm unsure, however, how other virtualization
platforms handle this issue...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
