Having used both for several months, I found the only workable option for myself was converting the database to KDB 1.x and using KeePassX.
129 karma · joined January 21, 2013
Having used both for several months, I found the only workable option for myself was converting the database to KDB 1.x and using KeePassX.
[1] https://support.stripe.com/questions/do-you-have-a-phone-num...
The site is, surprisingly, still online[1] and now accepting Perfect Money in place of Liberty Reserve. Unfortunately, they seem to still be using MD5 hashes even years later, for example:
TAIL/OaU1ERm1ZbUl5WWpGbE5UTm
bf30359e539686fb3eaa9abf9701938e
Exceptions would obviously include higher priced (OV/EV) certificates, which are no different cryptographically. Even the CA mentioned (GlobalSign) states this fairly clearly on their website.[1]
[1] https://www.globalsign.com/ssl-information-center/types-of-s...
Additionally, it seems that the more servers you have, the more you pay per server. Our use case would be several sysadmins (less than 5 users) accessing 50+ servers, which would mean we'd be paying ~$3/server/mo, whereas on the lower plan it works out to literally half that, at ~$1.5/server/mo, is pricing already finalized?
Thanks!
While this might not be a big consideration right now, this is almost a guaranteed loss in a UDRP/WIPO case against your domain, since you're in a very similar space. It might be a good idea to weigh your options prior to launch, as rebranding will inevitably become more difficult as you acquire users.
Not a reseller, owns their hardware and operates their own BGP network (with route optimized bandwidth/peering none the less), provides out of band management (VNC) and direct access to MRTG graphs etc.
Although they specialize in FreeBSD/OpenBSD and market heavily toward that crowd, they also offer the ability to install your own OS/Kernel if desired.
I wouldn't say they're the DigitalOcean if you're looking price wise, but having tried quite a few KVM VPS providers with FreeBSD, they've definitely been the best so far.
With gift cards, especially Starbucks gift cards, it's almost (if not literally) impossible to verify legitimacy. Generally, almost anyone attempting this type of fraud, even at the lower levels will:
- Mask the fact that funds are loaded with credit cards in the transaction log by purchasing gift cards with gift cards.
- Use services[2] which sell residential IP's by location (infected systems) as proxies
Unfortunately for the service your offering, Starbucks has an internal chain-disable feature which deactivates any gift cards "downline" of a fraudulently loaded card, hence it's entirely possible that after conducting a card transfer, even one fraudulent transfer could put the entire balance of your legitimate holding account at jeopardy, and the average Starbucks call center representative will be unable to help you.
Services like Cardpool (also offered in-store at Safeway locations) verify individuals identities prior to cash-in, however even with that the amount of fraud they experience is staggering. To give you an idea, the rate of successful, fraudulent transactions experienced by Cardpool in Safeway stores for 2012 was over 20%, compare to the average chargeback rate on an adult site, which is between 0.5 and 2%
I think you've made a smart move to put your project on hold until you have a better grasp of the entire situation.
In terms of the suspension you're referring to, they're an automated detection as far as I'm aware, so it really sounds like there might of been something happening that you were unaware of.
Regarding alternatives in this price point, you aren't going to find many options. If you're willing to step up your budget slightly, CloudVPS[1] and TransIP[2] in the Netherlands have both been great for us, and are still quite affordable considering what they provide.
If you're really stuck within your current budget, you might want to look at EDIS[3], whom we run several Slave DNS/MX servers with. They're about on-par with DigitalOcean pricing and offerings, with a much larger choice of locations, including the US.
In my experience, most database breaches result in data being sold, not used. It's more profitable and results in far less risk (Ex: 100k cards @ $2/ea via anonymous payment methods) vs attempting to use the cards.
As such, the people who end up actually creating the transactions are usually low level individuals whom are trying to figure out a way to "cash out"
Not to say there isn't a chance you're right, but card data is cheaply and readily available elsewhere, which is why I don't think this was related to a phishing attack. If there were other signs (ex: bank logins compromised, credit inquiries, etc.) then I'd be much more inclined to agree. Either way, it's hard to come to a certain conclusion based on the information provided in the article.
The processing rate is typically lower because of agreements between issuing banks and debit processing networks, and is a somewhat hot topic at the moment as technically pinless online debit transactions are only intended for when the customers identity has been "confirmed", such as individuals with running accounts at a wireless carrier.
However, for whatever reason, some big companies are being allowed to use the MasterCard Debit/Maestro/Visa Debit/STAR/PULSE networks in this manner. In this case that company is Starbucks.
I'd estimate the rate paid by Amazon/Starbucks for processing pinless debit is 0.8% or less. Compare this with the 0.9 - 2.2% interchange fee (depending on card type) they'd incur if they processed these transactions as credit. It might not sound like a lot, but at that scale it probably ends up being millions per day saved.
Additionally, cost benefit wise, card data sells for $2-3 max, while track data sells for much much more ($25-50), and typically someone capable of acquiring this data themselves would not be wasting their time with Starbucks card reloads.
Also, typically these are not "actual" (card-present, pin entered) debit transactions. Starbucks, much like Amazon, authorizes some online purchases as pinless debit card transactions, due to the lower processing rate incurred by the merchant. This can all be done completely online, for example, via Starbucks Online Reload system.[1]
This is truly nothing new, Gift card fraud has been booming since 2006-2007, when companies (starting with Starbucks, followed by Subway, Walmart[2], Whole Foods, etc.) began offering reloads to existing cards. Unfortunately, most of these companies have laughably bad fraud detection.
For example, Whole Foods uses a platform formerly known as "Giftango", which was rebranded as "InComm" in the last couple weeks. They quite literally will let a credit card thief reload hundreds of dollars from an IP anywhere in the world, to any gift card powered by their platform. No fraud scoring, velocity checks, geolocation, etc. You can imagine how easy this would be just by taking a look at their default gift card management portal, used by Whole Foods.[3]
Conveniently for credit card theives, WalMart even offers an option to reload a spreadsheet, or a CSV list of cards off a single credit card, easy right?[4]
Overall, I think this problem is only going to grow, especially with Cardpool acquired by Safeway, and now offering instant cash for gift cards in stores. This is an extremely easy method to cash out these fraudulently created gift cards, conveniently located at your local grocery store.
[1] https://www.starbucks.com/card/reload/one-time
[2] http://www.walmart.com/cp/Reload-Gift-Card/1097444
[3] https://app.giftango.com/GiftCardPortal/WholeFoods/GiftCardP...
In a way, riskScore simplifies the calculation, because it's a percentage instead of an arbitrary number. Depending on your business, I would consider starting at 30% for manual review, and 90%+ for auto refusal, making adjustments to the threshold from there.
This is based on their current riskScore system[1] (changing on January 1st, 2014) and 10 as an instant failure without review. Most orders will generate a non-0 score, however.
Another great tactic for preventing fraud is to never indicate an order has failed or a card hasn't been charged ('ghosting'), this is a tactic used heavily by Google for AdWords and other paid services.
Giving a clear indication of failure allows "carders" a way to easily figure out your detection algorithms by placing orders until one gets through, and share that information with others who will attempt to victimize your checkout process.
Most of these systems not only validate user login information (often in real time) but also place live authorizations on cards to make sure they are valid.
For example, the "credit card generator" you found probably just uses MOD10/Luhn to generate 'random' numbers, starting with 3/4/5 depending on the card type you select.
If you're looking to simply add friction to low level identitiy thieves, it'd probably work, but the real question is what is your motiviation?
Your time would be better spent contributing to existing phishing prevention projects, or attempting to coordinate with network providers to get these sites taken down more quickly, the majority of victimization occurs from large scale data theft or professional phishing / malware operations like IceIX/Citadel, not Joe Blow's Wells Fargo phishing page.
Although it's nowhere near fool proof it cuts out a good chunk of fraudulent orders. In our experience false positives have been very low (less than 2%) and detection has been fairly good (80%+)
I wouldn't deny orders completely based on MaxMind results, but if you have a human interpret the results / scoring or use it in conjunction with other methods, it's definitely a viable option.
Furthermore, you can use their call verification API, or even call card holders yourself whenever an order is placed to an alternate shipping address.
Fraud is just a fact of the business though, even with the best fraud detection and verification methods. Fraudulent orders may slip through, especially as you scale, and you should account for this as a cost of doing business.
Basic transforms / Regex / Basic if statements applied to trigger inputs/outputs would be invaluable.
Mistakes are understandable, however I think in-depth code review and auditing in any environment involving cryptography is an absolute must. Potentially, peoples lives could be jeopardized (either legally or physically) if they believed their communications were secure, when in fact they were not.
I have a quick question for you which might be of interest to others as well:
Why isn't SpiderOak open source yet?
I've read your FAQ answer[1] on this, however it doesn't really give a concrete explanation, besides "soon" and "licencing concerns" which is definitely disappointing.
I currently use my own, EncFS based sync solution, however I'd love to be able to use SpiderOak, or a third party open source application which supported syncing with SpiderOak (if you'd ever consider exposing an API/Protocol which allowed such.)
This is the only reason I'm not using your service currently, however I love the concept and hope you'll take it into consideration. It's likely I'm not the only one with similar concerns.
[1]: https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...
I'd say the real world risk of this is (fairly) low, however if you're legitimately worried about it, you can use EncFS over a network share or FUSE file system, to your own systems. In which case you'd be using entirely open source software.
If you're that worried about security though, you'd probably be better off using a container based encryption method, anyway, as it wouldn't leak timestamps, file sizes and other data which could be sensitive. EncFS has some known issues with metadata leaking, but it's a decent solution for most general use cases.
I personally don't think he has any PRC ties, however it does foster an interesting discussion, and isn't that what HN is all about?
I don't think that's the case here, however we really don't have any concrete evidence either way.
As far as law enforcement goes, you're spot on, physical distance is the least of anyone's concerns. The first consideration for law enforcement would probably be "How willingly will this jurisdiction work with us?"
You can do this on Linux (and presumably OS X, as well) fairly easily.
On Windows, there is a single-developer port of EncFS, which from what I've heard works fairly well: http://members.ferrara.linux.it/freddy77/encfs.html
A quick search turns up a guide which (at first glance) seems fairly comprehensive on how to set this up if you're unfamiliar with the way EncFS works: http://www.howtogeek.com/121737/how-to-encrypt-cloud-storage...
With that said, if you're worried about any highly confidential data, potential for watermarking attacks or plausible deniability, this is not the right solution for you.
If you're looking for a way to protect your data from dragnet surveillance, your provider, or low-level law enforcement interception, this is a great drop-in solution.
We've personally had assets and servers seized by the "Commercial Crimes Division" of the Hong Kong police, at the sole request of U.S. Law Enforcement.
With that being said, you may be correct in your speculation, especially since Hong Kong is definitely not known for it's free speech in regards to governmental or criminal matters, if he were truly going somewhere based on only their 'reputation', there are far more viable choices (Ex: Iceland or Ecuador)
Something is definitely fishy.
If I were to guess I can imagine the amount of effort it required probably outweighed any profits, especially if he was doing the letters manually. It must of been a cool experience, regardless.
I've also used EZGram, L-Mail (for individual letters) and DirectMailManager, PostalMethods and Click2Mail for business letters, so competition may be a factor as well.