Database relations, Bottle, NFC, NSA, Cloud security practices and procedures

Post date: Mar 15, 2014 4:24:19 PM

• During one integration project I found out that well, naming things is hard. Database contained tables Orders and Customers, Orders table had field CustomerId and Customers table had field CustomerId. Ok, let's join those. Hmm, doesn't seem to work out, what's wrong. Why, I check the SQL statement a few times. Check that both fields do contain similar looking smallish integer numbers. But yet it doesn't work out that way. I tried several ways and alas. Then I browsed the programs source looking for examples. Then I found one and I finally got the fact that the Customers table CustomerId field doesn't contain the CustomerId, but instead it contains the users customer id used by ERP and printed on invoices/receipts which is also used to log in to the service. So the CustomerId in Orders table refers to the Customers table ID field, which contains eh of course the internal CustomerId used in other database tables for joins. Simply, Wonderful, just pure joy. It's just great, how smallish things scan screw everything up. I'm sure I won't be the only one running into this trap with this project. That's my daily WTF.
• Checked out Camlistore. It's like BitTorrent Sync but completely open sourced.
• Thoroughly studied Bottle.py Minimal WSGI Framework. If I need to write extensive versatile integration web service, then I'll think I'll be using bottle.
• Some NFC, Mobile Payment, Chip & PIN security discussion comments: "Mobile payment NFC technology. Except, their tech guys clearly do not know that it simply doesn't have anything to do with it.
  • If NFC is really used for payments, then security is next huge question. I've been checking Finnish Mobile Authentication system, which is really nice and officially approved for identifying you. But there are just a few problems, like the question that if the handset is compromized it could present you wrong information about the transaction you're going to authenticate. Of course this same authentication scheme could be used over NFC instead of mobile network. But same insecurity issues remain. As long as the hardware with fixed or very secure firmware doesn't control whole process, it's clear that things can be overridden at other stages of the process."
  • and
  • "Mobile authentication and payments are already secure. Except just in the situation which I described. Having even exactly the same chip than on credit card doesn't make it secure either. Problem isn't with in the chip, problem is with the phones touch screen, display, UI and operating system. Because by modifying those, it's possible to deceive the user, about then transaction being authenticated and or capture the authentication PIN-code. Or even possible to do authorization using the chip, without ever displaying the request to the user, after PIN has been captured. We had long discussions about this topic, and it seems that those risks are real and possible. But I haven't personally done any code level checking how things are exactly handled. Chip cards aren't either secure, because the PIN code entry isn't done on the card directly, nor the card show's what's being exactly authenticated and to which authority. This also leaves multiple attack vectors open with chip & pin, even when using physical contacts, on wireless there are of course bit more probems, but it doesn't change the underlying aspects at all."
• Interesting articles: NSA taking over millions of computers around the world. Well, nothing new, that's exactly what I would do if it would be my job. I often wonder how confused people are about many things. They claim that something can't be done, even if it's totally clear it can be. If there isn't clear technical reason, why something is for sure impossible or extremely hard, it can be done and that's it. It might require many things to happen, but that's just matter of getting things arranged.
  • OWASP Top 10 web security issues.
  • Non-blocking transactional atomicity.
• Cloud security, network & system administration, practices and procedures:
  • It's just horrible see, how many network & system administrators taking care of customers security react to issues. Customer claims that they're unable to access services they need. Administrators start trouble shooting, and found out that there are IP range restriction rules for the service on the firewall. Their first assumption? Well, it must be the firewall, all problems are always caused by the firewall. First thing they do they'll remove all IP range restrictions from firewall. Well, did it solve the problem. Nope. Then they restart the server. It solves the problem by restarting the services. But guess twice, if they ever re-enable the firewall IP range restrictions? Well, of course they did not. They also failed to check if the service is actually running and or if the connection requests were actually being blocked by the firewall or not. In this case luckily the service being uncovered had proper authentication. But in some cases, no other authentication exists and connectivity limits are purely trusted on the firewall rules, which just can disappear when some issue is being troubleshooted.
  • It's just unbearably hard to watch how these massive fails happen over and over again. Somehow this just reminds me from the excellent TV show Mayday (Air Crash Investigation). Fail, after fail, lead to horrible end results.
  • Btw. These problems have been seen even with major ISP's, actually I the Finnish Telecom operator DNA most probably had similar issue to this which I'm describing. I've documented it in my blog earlier. They exposed their non-authenticating SMTPS service for whole Internet.
• More technical jargon terms: Computer Network Exploitation (CNE) and Computer Network Attack (CNA) and Network Intrusion Prevention System (NIPS) and Network Intrusion Detection System (NIDS).