On 9/Nov/18 20:26, Bill Woodcock wrote:
> That was true a few years ago, but it’s been at least a year since I’ve seen
> a swipe anywhere. The change happened quite quickly. It’s all been chip, or
> chip-and-pin, for at least a year.
In the last 2 years, I've seen the rise of PIN-based
> On Nov 8, 2018, at 1:11 AM, Mark Tinka wrote:
> It has always been curious to me how/why the U.S., with one of the
> largest economies in the world, still do most card-based transactions as
> a swipe in lieu of a PIN-based approach.
That was true a few years ago, but it’s been at least a
Once upon a time, Stephen Satchell said:
> On 11/08/2018 07:50 PM, Chris Adams wrote:
> > Signatures are no longer required for chip card transactions in the US,
> > except I think for transactions where the auth is done on the amount
> > before an added tip (restaurants).
>
> Signatures are
On 11/08/2018 07:50 PM, Chris Adams wrote:
> Signatures are no longer required for chip card transactions in the US,
> except I think for transactions where the auth is done on the amount
> before an added tip (restaurants).
Signatures are required for chip card transactions above a certain
On 9/Nov/18 02:22, Todd Underwood wrote:
>
> i generally find it amusing when people from other countries mock the
> US for not having PINs. this is just another way of saying "my
> country has high fraud rates and yours appears not to." :-) . you can
> see this in the comment below "If we
Once upon a time, Scott Christopher said:
> Swipe-and-sign (and now just swipe for small amounts) is for Visa,
> Mastercard, Discover transactions (called credit)
Signatures are no longer required for chip card transactions in the US,
except I think for transactions where the auth is done on
rge Michaelson
> Cc: North American Network Operators' Group
> Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling)
>
>
> Speaking of "cost" as a motivator, in South Africa, most of the banks
> are now using extra fees as a way to force users to do th
ors' Group
Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling)
Mark Tinka wrote:
> I hope the U.S. does catch-up. If we were swipe-based here, we'd all be
> broke :-). I know a number of major merchants in the U.S. now use PIN's,
> and I always stick to those when I travel there.
In the U.S., pin codes are required for EFTPOS transactions (called debit)
On 8/Nov/18 11:16, George Michaelson wrote:
> There are two parts of the problem. The first is the assumption of
> risk: the current model of operation in the US (like in other western
> economies) puts the onus of risk of misuse of the card on specific
> actors. When you change the basis from
There are two parts of the problem. The first is the assumption of
risk: the current model of operation in the US (like in other western
economies) puts the onus of risk of misuse of the card on specific
actors. When you change the basis from signature (fraud) to chip+pin
(leak of knowledge) you
On 11/Oct/18 21:31, Chris Adams wrote:
> Requiring an ID is also a violation of the merchant agreements, at least
> for VISA and MasterCard (not sure about American Express), unless ID is
> otherwise required by law (like for age-limited products). I've walked
> out of stores that required an
: bloomberg on supermicro: sky is falling
On Fri, Oct 12, 2018 at 4:39 PM Naslund, Steve wrote:
> >Make a second account at your bank. One account is 'storage' and has
> >all your money. You never use the 'storage account' ATM card for
> >anything outside your bank's ATM mach
On Fri, Oct 12, 2018 at 3:53 PM William Herrin wrote:
>
> Your bank charges you service fees?
>
> When I opened an additional checking account so I'd have something to
> link paypal to, it was free.
>
Plus you don't earn rewards points. I use an amex charge card for just
about everything,
--- snasl...@medline.com wrote:
From: "Naslund, Steve"
>Make a second account at your bank. One account is
>'storage' and has all your money. You never use
>the 'storage account' ATM card for anything outside
>your bank's ATM machines.
Doubling the service fees from your bank.
On Fri, Oct 12, 2018 at 4:39 PM Naslund, Steve wrote:
> >Make a second account at your bank. One account is
> >'storage' and has all your money. You never use
> >the 'storage account' ATM card for anything outside
> >your bank's ATM machines.
>
> Doubling the service fees from your bank.
Hi
> Doubling the service fees from your bank.
Depends on the bank. At my bank if you have a checking account, you can get a
basic savings acolytes for free. They also have free transfers between accounts
(which is very nice because on the basic savings account you are not allowed
and other
>Make a second account at your bank. One account is
>'storage' and has all your money. You never use
>the 'storage account' ATM card for anything outside
>your bank's ATM machines.
Doubling the service fees from your bank.
>The second one is where you only keep $50-$100 in
>it. When you use
> Make a second account at your bank. One account is
> 'storage' and has all your money. You never use
> the 'storage account' ATM card for anything outside
> your bank's ATM machines.
>
> The second one is where you only keep $50-$100 in
> it. When you use your ATM card it's only this
--- bj...@mork.no wrote:
There is nothing preventing a rogue online shop from
storing and reusing the CVV you give them. Or selling
your complete card details including zip code, CVV
and whatever.
-
As a side note on the tail end of this and as
"Naslund, Steve" writes:
> It only proves that you have seen the card at some point. Useless.
It doesn't even prove that much. There is nothing preventing a rogue
online shop from storing and reusing the CVV you give them. Or selling
your complete card details including zip code, CVV and
Once upon a time, b...@theworld.com said:
> But asking for photo id is a good thing for legitimate card holders,
> could reduce fraudulent in-person use of stolen cards.
Requiring an ID is also a violation of the merchant agreements, at least
for VISA and MasterCard (not sure about American
On October 11, 2018 at 13:41 s...@ottie.org (Scott Christopher) wrote:
> Robert Kisteleki wrote:
>
> > (this is probably OT now...)
> >
> > > I'm pretty sure the "entire point" of inventing CVV was to prove you
> > > physically have the card.
> >
> > Except that it doesn't serve that
On October 11, 2018 at 10:17 rob...@ripe.net (Robert Kisteleki) wrote:
> (this is probably OT now...)
>
> > I'm pretty sure the "entire point" of inventing CVV was to prove you
> > physically have the card.
>
> Except that it doesn't serve that purpose. Anyone who ever had your card
>
Robert Kisteleki wrote:
> (this is probably OT now...)
>
> > I'm pretty sure the "entire point" of inventing CVV was to prove you
> > physically have the card.
>
> Except that it doesn't serve that purpose. Anyone who ever had your card
> in their hands (e.g. waiters) can just write that down
(this is probably OT now...)
> I'm pretty sure the "entire point" of inventing CVV was to prove you
> physically have the card.
Except that it doesn't serve that purpose. Anyone who ever had your card
in their hands (e.g. waiters) can just write that down and use it later
hence defeating the
--- snasl...@medline.com wrote:
From: "Naslund, Steve"
You are free to disagree all you want with the default
deny-all policy but it is a DoD 5200.28-STD requirement
and NSA Orange Book TCSEC requirement. It is baked into
all approved secure operating systems including SELINUX
so it is
On Wed, Oct 10, 2018 at 02:21:40PM +, Naslund, Steve wrote:
> Allowing an internal server with sensitive data out to "any" is a
> serious mistake and so basic that I would fire that contractor immediately
> (or better yet impose huge monetary penalties.
I concur, and have been
> From: NANOG On Behalf Of Naslund, Steve
> Sent: Wednesday, October 10, 2018 1:06 PM
> If there was a waiver issued for your ATO, it would have had to have been
> issued by a
> department head or the OSD and approved by the DoD CIO after Director DISA
> provides a
> recommendation and it is
On October 10, 2018 at 17:58 snasl...@medline.com (Naslund, Steve) wrote:
> It only proves that you have seen the card at some point. Useless.
>
> Steven Naslund
> Chicago IL
>
> >I'm pretty sure the "entire point" of inventing CVV was to prove you
> >physically have the card.
>
If you're only talking about classified systems, sure.
But it didn't sound to me like we were only talking exclusively about
those kind of systems.
On Wed, Oct 10, 2018 at 11:08 AM Naslund, Steve wrote:
>
> Remember we are talking about classified intelligence systems and large IT
>
On Wed, Oct 10, 2018 at 1:53 PM Naslund, Steve wrote:
> Mr Herrin, you are asking us to believe one or all of the following :
>
> 1. You believe that it is good security policy to NOT
> have a default DENY ALL policy in place on firewalls
> for DoD and Intelligence systems handling sensitive
On 10/10/18, Mike Hale wrote:
> To be fair, the idea that your security costs shouldn't outweigh
> potential harm really shouldn't be controversial. You don't spend a
> billion dollars to protect a million dollars worth of product.
The problem with that idea is that it's almost always
Remember we are talking about classified intelligence systems and large IT
organization infrastructure (Google, Yahoo, Apple) here (in the original
Supermicro post).
That would be information whose unauthorized disclosure would cause grave or
exceptional grave harm (definition of secret and
To be fair, the idea that your security costs shouldn't outweigh
potential harm really shouldn't be controversial. You don't spend a
billion dollars to protect a million dollars worth of product.
That's hardly trolling.
On Wed, Oct 10, 2018 at 10:54 AM Naslund, Steve wrote:
>
> Mr Herrin, you
It only proves that you have seen the card at some point. Useless.
Steven Naslund
Chicago IL
>I'm pretty sure the "entire point" of inventing CVV was to prove you
>physically have the card.
Mr Herrin, you are asking us to believe one or all of the following :
1. You believe that it is good security policy to NOT have a default DENY ALL
policy in place on firewalls for DoD and Intelligence systems handling
sensitive data.
2. You managed to convince DoD personnel of that fact and
On Wed, Oct 10, 2018 at 1:06 PM Naslund, Steve wrote:
> Want to tell us what system this is?
Yes, I want to give you explicit information about a government system
in this public forum and you should encourage me to do so. I thought
you said you had some skill in the security field?
Regards,
On October 10, 2018 at 15:55 snasl...@medline.com (Naslund, Steve) wrote:
> The entire point of the CVV has become useless. Recently my wife was talking
> to an airline ticket agent on the phone (American Airlines) and one of the
> things they ask for on the phone is the CVV. If you are
If there was a waiver issued for your ATO, it would have had to have been
issued by a department head or the OSD and approved by the DoD CIO after
Director DISA provides a recommendation and it is mandatory that it be posted
at https://gtg.csd.disa.mil. Please see this DoD Instruction
It is good but has several inherent problems (other than almost no one using
it). Your card number is static and so is your pin. If they get compromised,
you are done. Changing token/pin resolve the static number problem completely,
compromise of a used token has no impact whatsoever.
On Wed Oct 10, 2018 at 09:17:37AM -0700, Brian Kantor wrote:
> I understand that in some countries the common practice is that the
> waiter or clerk brings the card terminal to you or you go to it at the
> cashier's desk, and you insert or swipe it, so the card never leaves
> your hand. And you
On Wed, Oct 10, 2018 at 11:25 AM Naslund, Steve wrote:
> You are free to disagree all you want with the default deny-all
> policy but it is a DoD 5200.28-STD requirement and NSA
> Orange Book TCSEC requirement.
And yet I got my DoD system ATOed my way earlier this year by
demonstrating to the
IVR credit card PIN entry is a thing
For example -
https://www.hdfcbank.com/personal/making-payments/security-measures/ivr-3d-secure
On 10/10/18, 9:57 PM, "NANOG on behalf of Naslund, Steve"
wrote:
True and that should be mandatory but does not solve the telephone agent
problem.
True and that should be mandatory but does not solve the telephone agent
problem.
Steven Naslund
Chicago IL
> I understand that in some countries the common practice is that the
> waiter or clerk brings the card terminal to you or you go to it at the
> cashier's desk, and you insert or
This is common in India but then chip and pin has been mandatory for a good few
years, as has 2fa (vbv / mastercard secure code) for online transactions.
Waiters would earlier ask for people's pins so they could go back and enter it
- back when a lot of the POS terminals were connected to POTS
I understand that in some countries the common practice is that the
waiter or clerk brings the card terminal to you or you go to it at the
cashier's desk, and you insert or swipe it, so the card never leaves
your hand. And you have to enter the PIN as well. This seems
notably more secure against
Sure and with the Exp Date, CVV, and number printed on every card you are open
to compromise every time you stay in the hotel or go to a restaurant where you
hand someone your card. Worse yet, the only option if you are compromised is
to change all your numbers and put the burden on your of
Having gone through this I know that it's all on you which is why no one really
cares. You have to notice a fraudulent charge (in most cases), you have to
dispute it, you have to prove it was not you that made the charge, and if they
agree then they change all of your numbers at which point
The entire point of the CVV has become useless. Recently my wife was talking
to an airline ticket agent on the phone (American Airlines) and one of the
things they ask for on the phone is the CVV. If you are going to read that all
out over the phone with all the other data you are completely
Well,
( I'm sorry but I cannot resist )
Seriously mate, trolling this list using "deny-all is bad m'kay" is
not a good idea.
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel:
Well,
Once you get the Expiry Date (which is the most prevalent data that
is not encoded with the CHD)
CVV is only 3 digits, we saw ppl using parallelizing tactics to
find the correct sequence using acquirers around the world.
With the delays in the reporting pipeline, they
You are free to disagree all you want with the default deny-all policy but it
is a DoD 5200.28-STD requirement and NSA Orange Book TCSEC requirement. It is
baked into all approved secure operating systems including SELINUX so it is
really not open for debate if you have meet these
On Wed, Oct 10, 2018 at 10:22 AM Naslund, Steve wrote:
> Allowing an internal server with sensitive data out to "any" is
> a serious mistake and so basic that I would fire that contractor
> immediately (or better yet impose huge monetary penalties.
> As long as your security policy is defaulted
They actually profit from fraud; and my theory is that that's why issuers have
mostly ceased allowing consumers to generate one time use card numbers via
portal or app, even though they claim it's simply because "you're not
responsible for fraud." When a stolen credit card is used, the
Yet this data gets compromised again and again, and I know for a fact that the
CVV was compromised in at least four cases I personally am aware of. As long
as the processors are getting the money, do you really think they are going to
kick out someone like Macy's or Home Depot? After all, it
On Wed, Oct 10, 2018 at 02:21:40PM +, Naslund, Steve wrote:
> For example, with tokenization there is no reason at all for any
> retailer to be storing your credit card data (card number, CVV, exp
> date) at all (let alone unencrypted) but it keeps happening over
> and over.
It's been a while
Allowing an internal server with sensitive data out to "any" is a serious
mistake and so basic that I would fire that contractor immediately (or better
yet impose huge monetary penalties. As long as your security policy is
defaulted to "deny all" outbound that should not be difficult to
Hey,
> Important distinction; You fire any contractor who does it *repeatedly* after
> communicating the requirements for securing your data.
>
> Zero-tolerance for genuine mistakes (we all make them) just leads to high
> contractor turnaround and no conceivable security improvement; A a
Important distinction; You fire any contractor who does it *repeatedly* after
communicating the requirements for securing your data.
Zero-tolerance for genuine mistakes (we all make them) just leads to high
contractor turnaround and no conceivable security improvement; A a rotating
door of
I have found that the article below provides some interesting analysis on the
matter which is informative as apposed to many articles which simply restate
what others have already said.
https://www.servethehome.com/bloomberg-reports-china-infiltrated-the-supermicro-supply-chain-we-investigate/
The risks of VPN aren't in the VPN itself, they are in the continuous
network connection architecture.
90%+ of VPN interconnects could be handled cleanly, safely, and reliably
using HTTPS, without having to get internal network administration
involved at all.
And the risks of key exposure
On Mon, 08 Oct 2018 08:53:55 -0500, Daniel Taylor said:
> Especially when you have companies out there that consider VPN a
> reasonable way to handle secure data transfer cross-connects with
> vendors or clients.
At some point, you get to balance any inherent security problems with the
concept of
That would be one way, but a lot of the problem is unplanned cross-access.
It's (relatively) easy to isolate network permissions and access at a
single location, but once you have multi-site configurations it gets
more complex.
Especially when you have companies out there that consider VPN a
> You just need to fire any contractor that allows a server with
> sensitive data out to an unknown address on the Internet. Security
> 101.
'cept the goal is not unemployed contractors
You just need to fire any contractor that allows a server with sensitive data
out to an unknown address on the Internet. Security 101.
Steven Naslund
>From: Eric Kuhnke
>
>many contractors *do* have sensitive data on their networks with a gateway
>out to the public Internet.
On 10/04/2018 03:13 PM, Scott Weeks wrote:
--- eric.kuh...@gmail.com wrote:
From: Eric Kuhnke
many contractors *do* have sensitive data on their
networks with a gateway out to the public Internet.
I could definitely imagine that happening.
scott
You are what you allow
--
The fact that there's a highway to Hell but only a stairway to Heaven says a
lot about anticipated traffic volume.
> On Oct 4, 2018, at 17:07, Naslund, Steve wrote:
>
> It would be really noticeable. In the secure networks I have worked with
> "default routes"
--- eric.kuh...@gmail.com wrote:
From: Eric Kuhnke
many contractors *do* have sensitive data on their
networks with a gateway out to the public Internet.
I could definitely imagine that happening.
scott
--- ra...@psg.com wrote:
From: Randy Bush
> Classified networks do not connect to other networks unless
> they are equally or higher classified.
that sentence makes no sense. if A can connect to B because B is more
highly classified than A, then B is connecting to a less classified
network
It would be really noticeable. In the secure networks I have worked with
"default routes" were actually strictly forbidden. Also, ACLs and firewall
policy is all written with Deny All policy first. Everything talking through
them is explicitly allowed.
The government especially in the three
On 04/10/2018 22:28, Naslund, Steve wrote:
>
> Quite different really. FIREWALK is really an intercept device to get
> data out of a firewalled or air gapped network. The exploit Bloomberg
> describes would modify or alter data going across a server’s bus. The
> big difference is the Bloomberg
On Thu, Oct 4, 2018 at 5:17 PM Scott Weeks wrote:
> --- snasl...@medline.com wrote:
>> The other thing I am highly skeptical of is the suggestion
>> of attempting to tap sensitive intel agency systems this way.
>> Talking to a C server is suicide from within their network.
>
> Classified networks
Remember it's the data that is classified, not the network. It does not matter
if you have IP connectivity, it matters if the classified data is allowed to
move over the connection. When a government agency talks about a "classified
network" they are talking about a network that has been
>> Classified networks do not connect to other networks unless they are
>> equally or higher classified. No internet connection.
>> Period.
Not quite but there are at least application level gateways. For example,
there are usually gateway that can let unclassified email flow into classified
On 04/10/2018 22:00, Naslund, Steve wrote:
> The other thing I am highly skeptical of is the suggestion of attempting to
> tap sensitive intel agency systems this way. Talking to a C server is
> suicide from within their network. How long do you think it would take them
> to detect a reach
Quite different really. FIREWALK is really an intercept device to get data out
of a firewalled or air gapped network. The exploit Bloomberg describes would
modify or alter data going across a server’s bus. The big difference is the
Bloomberg device needs command and control and a place to
> Classified networks do not connect to other networks unless
> they are equally or higher classified.
that sentence makes no sense. if A can connect to B because B is more
highly classified than A, then B is connecting to a less classified
network A.
randy
On Thu, 04 Oct 2018 14:10:07 -0700, "Scott Weeks" said:
> Classified networks do not connect to other networks unless
> they are equally or higher classified. No internet connection.
> Period.
Well, if your classified network is connecting to a higher classified net, then
*that* network is
The US' extensive reliance on third party commercial contractors to
implement a lot of programs, means that despite laws and SOW/PWS for their
contracts, many contractors *do* have sensitive data on their networks with
a gateway out to the public Internet. I have seen it. I have cringed at it.
On Thu, 04 Oct 2018 21:00:57 -, "Naslund, Steve" said:
> The other thing I am highly skeptical of is the suggestion of attempting to
> tap sensitive intel agency systems this way. Talking to a C server is
> suicide from within their network. How long do you think it would take them
> to
>
--- snasl...@medline.com wrote:
From: "Naslund, Steve"
The other thing I am highly skeptical of is the suggestion
of attempting to tap sensitive intel agency systems this way.
Talking to a C server is suicide from within their network.
> To me this looks like a Chinese version of the NSA FIREWALK product.
so the good thing about the trade war with china is that it keeps
implant designers fully employed on both sides. they can't just buy
eachother's implants; the tariffs would be too high.
randy
I can read but I am really finding it hard to believe that they all agreed to
even comment on it at all. Especially the PRC. Next question would be that if
Bloomberg was calling me for "months to a year" why not get out in front of it
in the first place? The whole story and its responses are
To me this looks like a Chinese version of the NSA FIREWALK product. Which
is a network implant built into a RJ45 jack intended to be soldered onto a
motherboard. The FIREWALK info came out with the Snowden leaks in 2013 and
the tech was years old at that time.
It is definitely more desirable to try and tap a serialized data line than the
parallel lines. The thing that made me most suspicious of the article is why
would anyone add a chip. It requires power and connections that a highly
detectable. Motherboard designs are very complex in the
On Thu, Oct 4, 2018 at 4:37 PM Naslund, Steve wrote:
> On the opposite side of the argument, does anyone think it is strange that
> all of
> the companies mentioned in the article along with the PRC managed to get a
> simultaneous response back to Bloomberg. Seems pretty pre-calculated to
> me.
On 2018-10-04 23:37, Naslund, Steve wrote:
I was wondering about where this chip tapped into all of the data and
timing lines it would need to have access to. It would seem that
being really small creates even more problems making those
connections. I am a little doubtful about the article.
I was wondering about where this chip tapped into all of the data and timing
lines it would need to have access to. It would seem that being really small
creates even more problems making those connections. I am a little doubtful
about the article. It would seem to me better to create a
On Thu, Oct 4, 2018 at 3:57 PM Mark Rousell wrote:
> The mystery object in the pictures in the article seemed to me
> to (sort of) resemble a surface mount power conditioning
> capacitor.
Though Bloomberg didn't go out of their way to say it, the photos were
"representative" of the chip
Supermicro's response at
https://www.supermicro.com/newsroom/pressreleases/2018/press181004_Bloomberg.cfm
On Thu, Oct 4, 2018 at 12:03 PM Randy Bush wrote:
> re:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
On Thu, Oct 4, 2018 at 2:26 PM William Herrin wrote:
> On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko
> wrote:
> > It would be better for them(AMZN, SMCI, AAPL) to prove that these
> > events did not take place - in court.
>
> "Can't prove a negative."
>
> > In the opposite case, even if
On 04/10/2018 20:26, William Herrin wrote:
> On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko wrote:
>> It would be better for them(AMZN, SMCI, AAPL) to prove that these
>> events did not take place - in court.
> "Can't prove a negative."
You can in effect do so by suing for defamation. It's
On Thu, 04 Oct 2018 15:26:15 -0400, William Herrin said:
> The Bloomberg article described them as looking like 'signal
> conditioning couplers" on the motherboard. There is no such part on
> server boards but maybe they meant optoisolators or power conditioning
> capacitors.
You overlook the
On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko wrote:
> It would be better for them(AMZN, SMCI, AAPL) to prove that these
> events did not take place - in court.
"Can't prove a negative."
> In the opposite case, even if this article is full of inaccuracies,
> judging by the discussions of
On 2018-10-04 21:52, Scott Weeks wrote:
--- matlock...@gmail.com wrote:
From: Ken Matlock
Would be remiss in our duties if we didn't also link
AWS' blog, in response to the Bloomberg article.
--
Every company and the Chinese gov't is saying
--- matlock...@gmail.com wrote:
From: Ken Matlock
Would be remiss in our duties if we didn't also link
AWS' blog, in response to the Bloomberg article.
--
Every company and the Chinese gov't is saying "no,
Bloomberg is wrong":
Would be remiss in our duties if we didn't also link AWS' blog, in response
to the Bloomberg article.
In short, AWS refutes many of Bloomberg's reporting in the article.
https://aws.amazon.com/blogs/security/setting-the-record-straight-on-bloomberg-businessweeks-erroneous-article/
Ken
On Thu,
98 matches
Mail list logo
