CVV numbers
In response to my comment about: > If I'm not supposed to not "tell anyone", why is it even printed where I can > read it? (Sorry for the extra not in there.) I got an off list suggestion of: http://www.cvvnumber.com/ It looks reasonable. But then, whois for cvvnumber.com says: Registrant: Domains By Proxy, LLC DomainsByProxy.com 15111 N. Hayden Rd., Ste 160, PMB 353 Scottsdale, Arizona 85260 United States Should I really take them seriously? -- These are my opinions. I hate spam.
Re: Dear Linkedin,
On Fri, Jun 8, 2012 at 9:48 PM, Michael Thomas wrote: > Linkedin has a blog post that ends with this sage advice: The sagest of which is to ask you to change your password on LinkedIn itself, *before* actually plugging the hole that led to the passwords leaking in the first place. Almost as sagely, they're only invalidating the passwords positively identified as having leaked, rather than assume all have, despite several security researchers concluding that the passwords that were posted publically were only a subset of those that were stolen. -link
Re: AUT-NUM ROUTE OBJECT
This has been sorted out now. On Fri, Jun 8, 2012 at 5:59 PM, Nick Hilliard wrote: > On 08/06/2012 17:55, Peter Ehiwe wrote: > > Authorisation for parent [as-block] > > using mnt-lower: > > not authenticated by: RIPE-NCC-RPSL-MNT > > http://apps.db.ripe.net/whois/lookup/ripe/mntner/RIPE-NCC-RPSL-MNT.html > > Nick > > -- Warm Regards Peter(CCIE 23782).
Re: CVV numbers
On Jun 9, 2012, at 1:06 AM, Hal Murray wrote: > Should I really take them seriously? Your call. That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a skimmer from being able to do mail-order/internet-order with your card number. The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas pump won't be able to capture it. There's a similar value on the magnetic strip that keeps the internet site you gave your card number and CVV to from being able to print cards and use them at the gas pump. Certainly they don't stop all fraud. They stop one type of fraud.
Re: CVV numbers
On 6/9/2012 12:06 AM, Hal Murray wrote: In response to my comment about: If I'm not supposed to not "tell anyone", why is it even printed where I can read it? (Sorry for the extra not in there.) The CVV number is simply to prove that the card is in your possession. The percentage of the sale that goes to Amex/Visa/Mastercard/Discover (etc) is determined by whether the merchant can supply various items, and the CVV is one of them. Running the card physically (where the merchant touches your card, and presumably verifies that you are you) gets taxed the lowest. The CVV is just meant to replace that verification. Sort of. I disapprove *strongly* of any online merchant that does not request this simple item, but it's not magic. I got an off list suggestion of: http://www.cvvnumber.com/ It looks reasonable. But then, whois for cvvnumber.com says: Registrant: Domains By Proxy, LLC Should I really take them seriously? No. No you should not. Here's the canonical Wikipedia entry, for those still playing along. http://en.wikipedia.org/wiki/Luhn_algorithm There's a few more grown-up words there. The best part is that it's a public algorithm. What's not to like? -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.
Re: CVV numbers
On Jun 9, 2012, at 7:14 AM, Lynda wrote: > On 6/9/2012 12:06 AM, Hal Murray wrote: >> >> In response to my comment about: >> >>> If I'm not supposed to not "tell anyone", why is it even printed where I can >>> read it? >> >> (Sorry for the extra not in there.) > > The CVV number is simply to prove that the card is in your possession. The > percentage of the sale that goes to Amex/Visa/Mastercard/Discover (etc) is > determined by whether the merchant can supply various items, and the CVV is > one of them. Running the card physically (where the merchant touches your > card, and presumably verifies that you are you) gets taxed the lowest. The > CVV is just meant to replace that verification. Sort of. I disapprove > *strongly* of any online merchant that does not request this simple item, but > it's not magic. > How does having the CVV number prove the card is in my possession? I have memorized the CVV in addition to the 16 digits of the cards I commonly use and routinely enter them into online ordering without retrieving the card. What prevents a fraudster from writing the CVV down along with the other card data? Sure, the CVV (in the case of CVV2) may not be included in the computer-readable mag-stripe or in swipe transactions, but I really don't see how CVV does anything to prove physical possession of the card at the time of the transaction (or at any time, in fact). >> I got an off list suggestion of: >> http://www.cvvnumber.com/ >> >> It looks reasonable. >> >> But then, whois for cvvnumber.com says: > >> Registrant: >>Domains By Proxy, LLC > >> Should I really take them seriously? > > No. No you should not. Here's the canonical Wikipedia entry, for those still > playing along. > > http://en.wikipedia.org/wiki/Luhn_algorithm Luhn seems to apply to the check digit (last of the (usually) 16 digits) on the face of the credit card and not to the CVV value. Owen
Re: My view of the arin db boarked?
On Fri, Jun 08, 2012 at 04:27:29PM -0400, Christopher Morrow wrote: > err, last 3 times I asked this I was shown the error of my ways, but > here goes... > > 209.250.228.241 - seems to not have any records in ARIN's WHOIS > database, everythign seems to roll up to the /8 record :( > > I see this routed as a /23: (from routeviews) > BGP routing table entry for 209.250.228.0/23, version 2072545487 > Paths: (33 available, best #19, table Default-IP-Routing-Table) > Not advertised to any peer > 3277 3267 174 27431 14037 > 194.85.102.33 from 194.85.102.33 (194.85.4.4) > Origin IGP, localpref 100, valid, external > Community: 3277:3267 3277:65321 3277:65323 3277:65330 > > If I look at the ASN in particular: AS14037 > no records exist for that in ARIN's WHOIS database either ;( If I look > at all the networks announced by AS14037: > 14037 | 204.8.216.0/21 | > 14037 | 209.250.224.0/19| > 14037 | 209.250.228.0/23| > 14037 | 209.250.242.0/24| > 14037 | 209.250.247.0/24| If you query filtergen.level3.com, they are expecting to see it from this ASN: Prefix list for policy as14037 = LEVEL3::AS14037 204.8.216.0/21 209.250.224.0/20 > 14037 | 64.18.128.0/19 | > 14037 | 64.18.159.0/24 | ...but not those, which are registered in ALTDB (as the /19)along with the squatted 204.8.216.0/21 and 209.250.224.0/20 route: 64.18.128.0/19 descr: RackVibe LLC origin: AS14037 admin-c:GC373-ARIN tech-c: GC373-ARIN notify: a...@6gtech.com mnt-by: MNT-6GTECH changed:a...@6gtech.com 20081007 source: ALTDB > none of them have any records in the ARIN WHOIS database :( The > upstream for this network is AS 27431 - JTL Networks > who seems to get transit/peer with 3356/174. Amusingly, AS27431 is still the RR contacts cording to the IRR. Score another one in the 'inaccurate IRR' column. > It's nice to see folk who use IRR databases to filter their customers > still permit this sort of thing to go on though: AS3356 I'm looking at > you... Here's a clue of future prefixes to watch for 3356 allowing from this particular nest: % whois -h filtergen.level3.com -- "-searchpath=ARIN;RIPE;RADB;ALTDB;LEVEL3 as27431" Prefix list for policy as27431 = ARIN::AS27431 LEVEL3::AS27431 ALTDB::AS27431 RADB::AS27431 RIPE::AS27431 66.132.44.0/24 66.132.45.0/24 66.132.47.0/24 69.36.0.0/20 209.41.200.0/24 209.41.202.0/24 209.115.40.0/24 209.115.41.0/24 209.115.42.0/24 209.115.43.0/24 209.115.108.0/24 216.28.47.0/24 216.28.134.0/24 216.29.53.0/24 216.29.115.0/24 216.29.116.0/24 216.29.117.0/24 216.29.121.0/24 216.29.122.0/24 216.29.152.0/24 216.29.194.0/24 216.29.247.0/24 % > I think first: "Where are the records for this set of ip number resources?" > and second: "Why are we still seeing this on the network with no way > to contact the operators of the resources?" You can try and contact the entities that are called 'RackVibe' accordin and '6G Tech' according to the various IRR registry entries for 14037 and 46496. Sketchy things which geolocate to Seacaucus? Whoda thunk. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
Re: Dear Linkedin,
> :: https://agilebits.com/onepassword (1Password) is one solution to > :: managing web site passwords. > > Only if you have an OS you have to pay for: apple or ms. The 1password password store has a perfectly usable local-only HTML app that lives in its data folder. http://help.agile.ws/1Password3/1passwordanywhere.html It works perfectly well from Linux and other OSes. I keep hoping for a free full-fledged Linux desktop port a la the android one ;-) [Or for seahorse integration, or whatever - I'm as big an open source advocate as nearly anyone, but having 1P on windows, osx, my droid, my ipad, and usable from my linux and solaris desktops... well, it's just too good not to give them a little money and a lot of respect for a good application.] best, --e
ITU funsies
While we will expect to see the Patrick S. Ryan & Jacob Glick paper linked on http://www.nanog.org/meetings/nanog55/abstracts.php?pt=MTk0OCZuYW5vZzU1&nm=nanog55 at some point, folks wanting a head start on digesting it can hit http://ssrn.com/abstract=2077095 Interestingly enough, http://wcitleaks.org/ launched last Wednesday... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
Re: Dear Linkedin,
My biggest problem still is the multiple computer issue. I am on at least 3-5 physical computers and 1-20 virtual machines, and 2 cellphones a day. I honestly do not want to store a database of passwords encrypted or not on an open service. As I have never had a virus or malware on any of my computers in the last 20 something years I trust my local machine/network more. The problem is it creates a distribution problem that is painful and tedious to deal with. So I stick with 10-15 long reasonably secure passwords that get used for stuff that just doesn't matter because there is an assumed no security (facebook, linkedin, whatever, and honestly who cares if this stupid stuff is hacked, its really just to avoid the hassle it would cause) and 1 unique password per critical sites (bank, benefits, financials). I store them on a local 3x3 levels of encrypted virtual drives with (2) 32-48 remembered passwords to access them just in case I forget any. Then I lock the 2 passwords up in a safe in a sealed envelope just in case something happens to me. If you are cautious on what and where you use them you honestly only need to change the criticals once a year or if there is a security event, heck outside of the bank account, I almost never login to any of the other accounts except to change the password. And for all other internet stuff, who cares, the assumption is it will be hacked, don't put stuff on the open internet that you don't want the entire world to know.
Re: CVV numbers
On 2012-06-09, at 10:56, Owen DeLong wrote: > > How does having the CVV number prove the card is in my possession? It doesn't, it merely proves you must have handled the card physically at some point since storing that value in a database is forbidden. Verified by Visa and the MasterCard equivalent actually "prove" that you are the rightful card holder. Unlike CVV numbers, they actually exempt the merchant from chargebacks (or did circa 2003). Alex
Re: CVV numbers
On 09-Jun-12 09:14, Joel Maslak wrote:
> On Jun 9, 2012, at 1:06 AM, Hal Murray wrote:
>> Should I really take them seriously?
> Your call.
>
> That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a
> skimmer from being able to do mail-order/internet-order with your card
> number. The CVV is not on the magnetic strip, so a skimmer installed at the
> ATM or gas pump won't be able to capture it.
This is CVV2; it is printed (but not embossed) on the card but not on
the magstripe. This is requested by online merchants to "prove" that
the card is in the customer's possession, since it won't show up on
carbons, receipts, etc. and in theory will never be stored by any
merchant (unlike the account number, expiration date, etc.). .
> There's a similar value on the magnetic strip that keeps the internet site
> you gave your card number and CVV to from being able to print cards and use
> them at the gas pump.
This is CVV1; it is on the magstripe but not printed on the card; this
is how brick-and-mortar merchants can "prove" that your card was in the
merchant's possession ("card present"), i.e. swiped rather than entered
by hand.
> Certainly they don't stop all fraud. They stop one type of fraud.
The two codes are targeted at very different types of fraud. What they
have in common is that submitting either a CVV1 or CVV2 number enables
merchants to get a better discount rate on their transactions. Given
the low margins in many industries, this can make the difference between
making a profit and losing money on a sale, which is why many merchants
refuse transactions without CVV1 or CVV2. Merchants in industries with
higher margins often don't care; they'll submit CVV1 or CVV2 when
convenient, but they won't let not having them block the sale.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Dear Linkedin,
A friend would print in block letters in the sig area of his credit cards "ASK FOR PHOTO ID". He said that almost always cashiers et al would give a cursory glance like they were checking his signature and say thank you and hand him back his card. Maybe someone mentioned this but merchant card contracts generally (always?) require that you NOT store CVVs when the transaction is over. It's just some double-check remotely that you physically have the card, or did once in the past, etc. and doesn't imprint. Credit card security is about percentages not absolutes, about the cost-benefit analysis. Many years ago I interviewed at a company which was building a big honking multi-processor. They had $150M in pre-orders from BIG CREDIT CARD COMPANY dependent on the machine being able to run a bunch of anti-fraud algorithms they knew were good (run against historical data) but couldn't run in real-time, no iron was fast enough at the time. BIG CREDIT CARD COMPANY estimated, as I remember, that if they could run those algorithms it would catch about $50,000/hour in fraud, so the $150M was a good investment from their point of view. I didn't take the job and they never finished the system. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: CVV numbers
On Sat, Jun 09, 2012 at 02:18:15PM -0400, Alexandre Carmel-Veilleux wrote: > On 2012-06-09, at 10:56, Owen DeLong wrote: > > > > How does having the CVV number prove the card is in my possession? > > It doesn't, it merely proves you must have handled the card physically at > some point since storing that value in a database is forbidden. > > Verified by Visa and the MasterCard equivalent actually "prove" that you are > the rightful card holder. Unlike CVV numbers, they actually exempt the > merchant from chargebacks (or did circa 2003). > > Alex Before the days of online transactions, how many people even knew a portion of their CC let alone the verification tag? The main weakness of CVV2 these days is "form history" in browsers. (auto complete). Now, if someone can get ont your PC, they not only get the credit card number (which there are myriad different ways to get) but the CVV as well so that mechanism is, now, all but useless. Add to that the fact online merchants don't even have to appear in the same country, let alone region, and the "location of purchase relative to the home residence of the user" doesn't mean much either so can't act as an effective secondary if the information were to be captured. Just like all other forms of security and fraud protection that we in the online community try to enable, eventually something comes along that makes the job a lot harder. Having these mechanisms is better than not having them but there will never be a perfect system. -Wayne --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: CVV numbers
On June 9, 2012 at 12:12 w...@typo.org (Wayne E Bouchard) wrote: > > The main weakness of CVV2 these days is "form history" in browsers. > (auto complete). Now, if someone can get ont your PC, they not only > get the credit card number (which there are myriad different ways to > get) but the CVV as well so that mechanism is, now, all but useless. Oh c'mon, all but useless? Look at all the ifs/ands/buts. They need access to your form history which actually is useless if the merchant's form just uses a password-type field, etc. Yeah, a lot of these techniques are useless if your computer etc is completely pwned. But they help if you're not. Credit card fraud prevention is all about percentages, not absolutes. Even just requiring a valid credit card number and expiration date and nothing else probably prevents, I dunno, 98%+ of all potential fraud, probably 99%+. The rest is about squeezing down that last percentage point or two and generally discouraging crooks from trying. One of the PITA frauds credit card companies deal with is someone in the household, like your teenage kid, taking your card physically out of your wallet and using it w/o your permissin and then you call in when you see the bill that you never ordered $100 from iTunes or bought any cool sneakers at the mall. That's probably more common than a lot of the other frauds you imagine. A lot of these techniques at least prove that *someone* had your card physically if they suspect this was not fraud but, rather, "unauthorized use". People will also try to deny charges they simply regret, like a night at a bar with strippers particularly that one in the blue hot pants, who the h*** KNEW she got $300 for a lap dance and $50/glass for the Kristal, doesn't seem fair not fair at all...it's some backpressure. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: Password safes &c. (was: Dear Linkedin,)
Original Message - > From: "Lyndon Nerenberg" > The only way to ensure your personal passwords are never compromised > is to kill yourself after destroying all physical copies of those > passwords. While ultimately secure, you won't be able to do your daily > online banking. No, but on the positive side, the issue will be less pressing to you. User-side authentication security is a multi-dimensional problem, and it is probably not theoretically possible to optimize any given instance for all of the possible vectors simultaneously. Different individuals need to make their own threat estimate, and decide what approach they want to take to it. Of course, 95% of the affected audience wouldn't know what the phrase "threat estimate" meant, even if you threatened them. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: CVV numbers
There is a reason part of most scanners that verify the PCI standard look for autocomplete=off on credit card number and cvv2 fields. This is specifically it. -j On Sat, Jun 9, 2012 at 12:30 PM, Barry Shein wrote: > > On June 9, 2012 at 12:12 w...@typo.org (Wayne E Bouchard) wrote: > > > > The main weakness of CVV2 these days is "form history" in browsers. > > (auto complete). Now, if someone can get ont your PC, they not only > > get the credit card number (which there are myriad different ways to > > get) but the CVV as well so that mechanism is, now, all but useless. > > Oh c'mon, all but useless? Look at all the ifs/ands/buts. They need > access to your form history which actually is useless if the > merchant's form just uses a password-type field, etc. > > Yeah, a lot of these techniques are useless if your computer etc is > completely pwned. But they help if you're not. > > Credit card fraud prevention is all about percentages, not absolutes. > > Even just requiring a valid credit card number and expiration date and > nothing else probably prevents, I dunno, 98%+ of all potential fraud, > probably 99%+. > > The rest is about squeezing down that last percentage point or two and > generally discouraging crooks from trying. > > One of the PITA frauds credit card companies deal with is someone in > the household, like your teenage kid, taking your card physically out > of your wallet and using it w/o your permissin and then you call in > when you see the bill that you never ordered $100 from iTunes or > bought any cool sneakers at the mall. > > That's probably more common than a lot of the other frauds you imagine. > > A lot of these techniques at least prove that *someone* had your card > physically if they suspect this was not fraud but, rather, > "unauthorized use". > > People will also try to deny charges they simply regret, like a night > at a bar with strippers particularly that one in the blue hot pants, > who the h*** KNEW she got $300 for a lap dance and $50/glass for the > Kristal, doesn't seem fair not fair at all...it's some backpressure. > > > -- >-Barry Shein > > The World | b...@theworld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, > Canada > Software Tool & Die| Public Access Internet | SINCE 1989 *oo* > >
Choosing Passwords
- Original Message - > From: "Hal Murray" > Security is a tradeoff. I think there are two cases for passwords. I'll > call them important and junk. I'm willing to store the junk ones in a file > or piece of paper that I'm careful with. I have to memorize the important > ones. Well, my personal approach to this -- one which I'm well aware is disparaged by Security Professionals -- is tiered passwords. I have one password for 'throwaway' accounts -- drive-forum postings and the like, another password for slightly more important accounts -- forums in which I participate regularly and the like, a third password for actual machine accounts, VPNs and similar things like equipment control panels, and finally a tier for accounts that people can actually change my life or spend my money; things like eBay, PayPal, etc -- on this tier, each password is actually distinct. Finally, there's a top-emergency fallback password, which I use for password safes, which is -- as nearly as I can determine, unresearchable, even if I told you its description. All of these passwords are rule/pattern constructed, using either The XKCD Rule, or one of a couple of my own construction, and each individual password is infixed after what it applies to, so as to make the actual final passwords *never be the same string of characters*, the infix going in a nondeterministic place in the string. This puts enough bits of entropy into the passwords to make them relatively strong -- sites with strength checkers on password set tend to like them a lot -- while keeping them all unique so they can't be cross referenced... and making them complex enough that they cannot be dictionary cracked either. I am, of course, a special case; I've been a system administrator for 30 years; this is my business -- I am willing to put the necessary energy into it as part of my work. I realize that lots of people (where, by lots, I mean several billion) aren't -- either because they don't understand why its important, or because they don't care, or because "it's someone else's fault when $3800 gets taken out of my bank account cause I'm a careless slob". TL;DR: Everyone, admin, user, or civilian, has to make their own decisions about how much work they want to put into security -- and *we* have to find ways to explain the choices so that Joe Q. Sixpack can understand *why it's important to him to think about it*. That's a sales pitch; engineers are *singularly* unsuited to it, in general. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: CVV numbers
- Original Message - > From: "Owen DeLong" > How does having the CVV number prove the card is in my possession? > > I have memorized the CVV in addition to the 16 digits of the cards I > commonly use and routinely enter them into online ordering without > retrieving the card. > > What prevents a fraudster from writing the CVV down along with the > other card data? Nothing, but lots of fraud scenarios don't involve a bad actor taking physical posession of your card: magstripe skimmers and charge-slip carbons being only 2 off-hand examples. Clearly, the percentage of fraud it blocks is more than the amount it costs. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Dear Linkedin,
- Original Message - > From: "Barry Shein" > A friend would print in block letters in the sig area of his credit > cards "ASK FOR PHOTO ID". He said that almost always cashiers et al > would give a cursory glance like they were checking his signature and > say thank you and hand him back his card. This seems like an altogether excellent time to haul out *this* old chestnut: http://www.zug.com/pranks/credit/ FWIW, My cards have always said SEE ID, and I get about a 40% or so hit rate on that. It's been odd recently, cause I sometimes forget, and the privacy reflex kicks in and makes me want to say "Why??" :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: ITU funsies
Somebody sent a copy of the TD64 working doc to Milton Mueller of IGP/ICANN-NCSG not yet on wcitleaks. Be aware, the new treaty will get rid of SPAM !! http://www.internetgovernance.org/2012/06/06/td-64-for-breakfast/ -J On Sat, Jun 9, 2012 at 12:21 PM, Joe Provo wrote: > > While we will expect to see the Patrick S. Ryan & Jacob Glick > paper linked on > http://www.nanog.org/meetings/nanog55/abstracts.php?pt=MTk0OCZuYW5vZzU1&nm=nanog55 > at some point, folks wanting a head start on digesting it can > hit http://ssrn.com/abstract=2077095 > > Interestingly enough, http://wcitleaks.org/ launched last > Wednesday... > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG >
Re: Dear Linkedin,
On 06/09/12 15:43, Jay Ashworth wrote: - Original Message - From: "Barry Shein" A friend would print in block letters in the sig area of his credit cards "ASK FOR PHOTO ID". He said that almost always cashiers et al would give a cursory glance like they were checking his signature and say thank you and hand him back his card. This seems like an altogether excellent time to haul out *this* old chestnut: http://www.zug.com/pranks/credit/ FWIW, My cards have always said SEE ID, and I get about a 40% or so hit rate on that. It's been odd recently, cause I sometimes forget, and the privacy reflex kicks in and makes me want to say "Why??" :-) Cheers, -- jra My personal favorite is to ask if I spelled my name correctly? Lyle Giese LCR Computer Services, Inc.
Re: Dear Linkedin,
On Sat, Jun 9, 2012 at 10:52 AM, wrote: > My biggest problem still is the multiple computer issue. I am on at least > 3-5 physical computers and 1-20 virtual machines, and 2 cellphones a day. > I honestly do not want to store a database of passwords encrypted or not > on an open service. > Security is all about trade-offs. In this case it's the trade-off between storing an excrypted password database on a 3rd party server, v's re-using passwords and having (potentially) weaker passwords as a result of not doing so. Personally I use KeePass, with the database stored on a cloud-synced directory. To decrypt the KeePass database requires both a Passwords AND a Key file, which is NOT synced to the cloud. IMHO this gives the best of both worlds - easy syncing between multiple computers and the ability to use unique, very strong passwords with all websites. But also very strong security in the case that the KeePass database is somehow compromised from the cloud service, as both the password and keyfile would be required to decrypt. Scott
Re: CVV numbers
On 6/9/12, Alexandre Carmel-Veilleux wrote: > On 2012-06-09, at 10:56, Owen DeLong wrote: >> How does having the CVV number prove the card is in my possession? > It doesn't, it merely proves you must have handled the card physically at > some point since storing that value in a database is forbidden. [snip] Someone must have something in a database that can easily derive the CVV2 number; otherwise there would be no way for it to be verified that the correct number has been presented, there's really no hashing scheme for 3-digit numbers that cannot be trivially brute-forced, once any salting procedure is known by an attacker. I bet there is at least one small retailer out there who takes phone orders and gathers CVV2, and at least one POS software developer out there who is unaware of, has ignored, or has intentionally/unintentionally disobeyed the rule about never storing CVV2 values in a database,and does at least one of these things: transmits it without storing but fails to encrypt it (e.g. number sent to a backend with unencrypted XMLRPC transaction), records it in a database, e-mails the data internally, puts it in a spreadsheet, and stores it as data at rest (encrypted it or not), and fails to scrub it, eg deleted but not overwritten file on a computer, file on a share, e-mail saved in a folder, writes it down, or otherwise misappropriates the CVV2 value together with the CC# and Expdate. In other words CVV2 is a "weak" physical "proof" mechanism that only works if all parties involved obey the rules perfectly without error, even parties such as merchants who are not necessarily trustworthy, but even if trustworthy may also have kept record of CVV2 CC Expdate by accident, poor process, or failure of staff to follow established procedures for the handling of the data. -- -JH
Re: CVV numbers
On Sat, Jun 9, 2012 at 7:14 AM, Joel Maslak wrote: > That said, the purpose of CVV is to stop *one* type of fraud - it's to > stop a skimmer from being able to do mail-order/internet-order with your > card number. The CVV is not on the magnetic strip, so a skimmer installed > at the ATM or gas pump won't be able to capture it. > No, it's to stop more than one type of fraud - however your point is correct in that it's not designed to stop *all* fraud, it's just one of many layers of prevention. In addition to the one you've mentioned, the CVV2 also stop the card being fraudulently being used in any situation where the card number has been leaked, such as a database of card numbers being hacked, a receipt with the full number on it (rare if at all existent these days), etc. The rules on CVV2 numbers basically say that the number can never be recorded by the merchant after the transaction has been processed, which pretty much means that they can't store it at all in any form. If a database is hacked, the CVV2 number will not be there. Scott
Re: CVV numbers
On Sat, Jun 9, 2012 at 12:12 PM, Wayne E Bouchard wrote: > The main weakness of CVV2 these days is "form history" in browsers. > (auto complete). Any website requesting a CVV2 in a form field without the form history/autocomplete being disabled is in breach of PCI compliance, and risks losing their ability to accept credit cards. That's not to say there aren't some that do it, but to call this the "main weakness" of CVV2 is simply wrong. Scott
Re: CVV numbers
On Sat, Jun 9, 2012 at 2:25 PM, Jimmy Hess wrote: > Someone must have something in a database that can easily derive the > CVV2 number; > There is no way to "derive" the CVV2 number. It is little more than a random number assigned to the card. > otherwise there would be no way for it to be verified that the correct > number has > It is verified by comparing it to the known CVV2 number stored by the credit card company/bank that issued the card. > I bet there is at least one small retailer out there who takes phone > orders and gathers CVV2, and at least one POS software developer out > there who is unaware of, has ignored, or has > intentionally/unintentionally disobeyed the rule about never storing > CVV2 values in a database, Gathering CVV2 number over the phone is completely valid. It's even valid to write them down, as long as they are destroyed as soon as the transaction has been completed. Of course there are people that disobey/ignore/don't know the rules - no level of security will ever be perfect in this regards - it's all about making the security better and reducing the rate of fraud/chargebacks. > In other words CVV2 is a "weak" physical "proof" mechanism that only > works if all parties involved obey the rules perfectly without error, > Correct. It's a "weak" physical "proof" mechanism that has succeed in having a very significant reduction in fraudulent transactions/chargebacks across pretty much the entire industry. Remind me again what your point was? Scott
Re: CVV numbers
On 9 June 2012 22:42, Scott Howard wrote: > There is no way to "derive" the CVV2 number. It is little more than a > random number assigned to the card. > [...] > It is verified by comparing it to the known CVV2 number stored by the > credit card company/bank that issued the card. > > I don't think this is correct - I believe the Wikipedia entry is accurate: ---snip--- CVC1, CVV1, CVC2 and CVV2 values are generated when the card is issued. The values are calculated by encrypting the bank card number (also known as the primary account number or PAN), expiration date and service code with encryption keys (often called Card Verification Key or CVK) known only to the issuing bank, and decimalising the result ---snip--- http://en.wikipedia.org/wiki/Cvv2 I suspect the issuing banks can share their CVKs with the card scheme operators (Visa, MC, Amex) if they want them to validate transactions on their behalf. Aled
Re: CVV numbers
On Sat, Jun 09, 2012 at 02:34:03PM -0700, Scott Howard wrote: > On Sat, Jun 9, 2012 at 12:12 PM, Wayne E Bouchard wrote: > > The main weakness of CVV2 these days is "form history" in browsers. > > (auto complete). > > Any website requesting a CVV2 in a form field without the form > history/autocomplete being disabled is in breach of PCI compliance, and > risks losing their ability to accept credit cards. And convenience trumps pseudo-security yet again; Chrom(ium) asks me if I want to save my CC details when I put them in (to which I tell it not just "no", but "are you *nuts*?"); presumably this is on forms which include autocomplete=off, since it happens often enough. So I would assume that this PCI compliance tickbox is being ignored by browsers. Whee! - Matt -- Ruby's the only language I've ever used that feels like it was designed by a programmer, and not by a hardware engineer (Java, C, C++), an academic theorist (Lisp, Haskell, OCaml), or an editor of PC World (Python). -- William Morgan
Re: Dear Linkedin,
On 6/9/12, Scott Howard wrote: [snip] > Security is all about trade-offs. In this case it's the trade-off between > storing an excrypted password database on a 3rd party server, v's re-using > passwords and having (potentially) weaker passwords as a result of not [snip] Yes. Using an encrypted online password vault is a trade-off. Risks that are unaffected: o A randomly generated password might be more guessable than a human-created password, if generated by an insecure PRNG, for example, if the possible generation outcomes for given input parameters can be predicted through analysis. o A password can easily be stolen by malware on a computer the password is typed on that logs keystrokes and mouse clicks (even a vault's master password). o A password can easily be stolen if transmitted to a remote site unencrypted, by a computer on the local or remote LAN with malware infection (even a switched LAN). o If either endpoint's SSL certificate (or a CA) is compromised, a MITM attack can be used to learn the contents of encrypted communications. o A password can be stolen by malware if stored temporarily at rest or temporarily in RAM in an unencrypted format. o A password can be stolen if stored at rest in unencrypted format. o A password can be stolen, even if encrypted, if the symmetric encryption key can also be stolen. New risks increased in magnitude: o If malware running on a computer is aware of the password vault application, it may be able to maliciously modify the executable code of the password vault application in memory, resulting in data compromise. o Your password data is vulnerable to local compromise if your master pw is guessed or stolen. (Use a vault with multi-factor authentication to mitigate). o If password vault data is stolen, the thief has a convenient list of accounts. Risk can be reduced by using multiple vaults of different types for different security levels/use frequency. o If the password vault software fails, DB is corrupted, or the online password vault service goes offline, you can lose access to your accounts, because you don't remember the passwords. o The pass vault is an additional piece of software; if the software developers' systems are compromised, it might be possible for malicious code to be inserted in the password vault application. o If the password vault software has a bug, the encryption doesn't work properly, or fails to maintain good security hygene, all your passwords may be vulnerable. For example, if you keep a GPG encrypted list of passwords, and you create a "temporary plain text file"when re-encrypting to create a new encrypted list, passwords are vulnerable to theft during this process, and afterwards via latent disk analysis techniques. Examples of Risks mitigated by online encrypted password vault VS shared or similar passwords that are memorized: o Reduced risk of loss of access to account, resulting from forgetting which password was selected for a particular account, or adverse password changes enforced by "password setting" or "mandatory password change" policies. o No need to use short/guessable passwords (less than 16 characters); high-entropy passwords can be chosen which can only be attacked by brute force, and which will take massive amounts of money or time to successfully attack. o If the login password to one site is compromised, guessed, or accidentally disclosed by any means; many of your accounts are at increased risk. Risks eliminated pw vault VS passwords written down on a slip of paper: o No risk of losing the paper, resulting in account compromise and loss of access o No risk of a piece of paper being stolen. o No need to use short passwords (less than 32 characters) that can easily be written down -- -JH
