Forgot your password?
typodupeerror

Fixing Security Through Obscurity? 66

Posted by Cliff
from the clothing-the-emperor dept.
LineNoiz asks: "I work as a junior developer at a small company that sells check printing software. One of my company's favorite things to tell customers is how secure our product is and how it will reduce check fraud (we even sell check fraud insurance). I cringe everytime I hear them say it, because I know that it is 'secure' only because of it's relative obscurity. I personally know very little about security, and really have no idea what it would take to make our product secure. All I really know is that this is a problem waiting to happen. How can I convince my managers that our security is nothing to brag about? How can I convince them to spend the time and money to make it secure? Where can I myself go to learn more about security and what it would take to make/keep it secure?"
This discussion has been archived. No new comments can be posted.

Fixing Security Through Obscurity?

Comments Filter:
  • by Tumbleweed (3706) on Wednesday October 22, 2003 @06:01PM (#7285013)
    > How can I convince my managers that our security is nothing to brag about?

    The risky way would be to create and demonstrate an exploit. Et voila, they're convinced.

    Of course, you run the risk of being replaced by a security-knowledgable programmer once you do so. :)

    To help you convince them, learn about security, and present a fix for the problem. Then tell them they can REALLY go crazy on the security promotion aspect once they do so. Help them sell the product, and you may be sitting in the cat-bird seat, whatever that is.
    • by innosent (618233) <.jmdority. .at. .gmail.com.> on Wednesday October 22, 2003 @06:28PM (#7285244)
      What exactly is ever secure about a check? He says it's a check printing company, so what could possibly be secure about it? You can order printable checks from just about anywhere, with all the "security" features on them, get a MICR toner cartridge (if you even care when the bank complains about having to hand-enter your checks because they're not magnetic), and print all the checks you want. This is probably just some kid who's finally figured out how banks operate.

      "Security" features on checks usually are only to prevent someone from photocopying the check, and do nothing to stop someone with a box of checks and a laser printer. No matter what you do while printing the check, Checks are not secure. Most businesses print their checks, and print them in the same manner as I just described, and there is nothing that can be done about it, because banks will cash any valid check, which means only that the account number and signature must match their records (you could write the information on a napkin and the bank would take it, it is a valid check), and banks will rarely flag a check for a bad signature.

      If someone gets one of your "secure" checks from a client of this guy's company, orders a box of checks from them, and prints checks, then even the client may not realize that they didn't write the check. That's how checks are, deal with it. If you don't trust the person you're writing a check to, don't use a check, it's just that simple. By the way, it is amazing to me how the banks always say "don't give out your account information to anyone" (and no, I'm not talking about PINs) when it's printed on every check. The only thing worth making "secure" (as in unable to be scanned/photocopied) about a check is the signature line, and very few companies do this, since the only effective means I know of to do this requires a color laser printer and an electronic signature image. (red/black printing scheme, etc).
      • Ignore the fact that it's a check/cheque/Czech printing company and focus on the question.

        I guess they have some sort of software which allows people to order cheques remotely (either dial up or internet) and have them sent to their business or house etc. This poses the security risk.

        • Maybe you are missing the point as well. The original question was pretty vague. I would guess that it is the check printing software and the checks themselves that they are claiming are secure, not the process by which checks are ordered. So what does it mean to have "secure check printing software"? Will it only print checks if it can verify that the account is legitimate? Does it attempt to verify the address on the checks? Even so what is secure about checks? Just about nothing. So what does t
          • I'm not asking the question "How can I make this more secure?" I pretty much know the answer to that. I'm asking "How do I convince the management of a small company to spend money on something that has no immediate ROI?" I'm also asking for some good sources on where I could find some information about writing secure code. That's all I'm looking for.

            As for your good and perfectly valid questions, you are right: checks are inherently insecure. It's not the checks that we secure (although storing bunches of
        • by greenhide (597777)
          I guess they have some sort of software which allows people to order cheques remotely

          That's not the impression I got.

          This guy was really vague about the security concerns he had -- I guess he must believe in the "security through obscurity" method. :-p

          Frankly I think this was way too generic of an Ask Slashdot. If he'd said whether his security concerns were regarding the products that we sold (and again, since they're pieces of paper I'm not sure how you can "secure" them), the software used to print t
      • Umm, commercial-class check software produces a list of checks that were printed, and cleared by an authorized human being at the company. Each of these files is sent to the bank who holds the account the check was written against. The banks check against these records when the check is processed, then it comes back to the company in a file of cleared checks. Many banks are using thumbprint ID on checks, and photocopy your ID if you aren't an accountholder.

        Also, all of our checks have the signature pr

        • Ok, I haven't had any experience with sending the bank a list of checks (which certainly makes sense for larger companies, no so much for smaller ones), but even with this added security effort, what if a check is copied, using the same stock and MICR toner? Does the bank know who the check was made out to? Even if they do, couldn't a payee cash two identical checks? Which one would the bank cash then? And no, they don't always check if the signature is MICR at the bank. They check the MICR account num
      • the account number and signature must match their records (you could write the information on a napkin and the bank would take it, it is a valid check)

        Is this really true? I'm not familiar with the laws regarding negotiable instruments, they are weird. Is it the case that if I owed someone money and didn't have a checkbook, I could make a check from scratch with a pen and scrap paper and the bank would honor it so long as it included the right information?
        • Some banks may have a policy against honoring this kind of check - but not all of them. A coworker and I were having this very discussion a few years back. We decided to test it out. I wrote the check on a piece of paper and gave it to him. His bank wouldn't take it for deposit unless I came with him and showed them my ID. Even after that, it took two months to clear and I got called about seven times to verify that I really did want it to go through. The check was for ten dollars, the processing fees came
    • by Anonymous Coward
      The risky way would be to create and demonstrate an exploit. Et voila, they're convinced.

      That's like saying that the way to demonstrate that guns are deadly is to kill someone. Et voila, tres stupid.
      • Tres stupid, yes, your example is quite stupid. I didn't say he should trash his employer's systems or anything like that - just _demonstrate_ an exploit, in house. He's an employee. Develop some common sense, dipstick.
    • Dont knock the security thru obscurity. It seems to work well for Linux, BSD, OSX, etc.

      Another point- he says his company sells insurance. I would at this point bet this insurance comes from an outside underwriter, and thus their company has their liability covered.

      Give it up, you will never get the company to spend money on security. There is no reason to: they are insured! The mess-up wont cost them anything, but being proactive will. Lets say something gets messed up; I bet they get enough money fro

      • > Dont knock the security thru obscurity. It seems to work well for Linux, BSD, OSX, etc.

        You don't seem to know what "security through obscurity" _means_, if you think that's what Linux & the *BSDs rely on.

        re: insurance

        If the security problem (whatever it is) becomes publicly known, that could damage business, insurance or no, and could cause insurance premiums to go up, conceivably, so it's in their best interests to fix this ASAP, whether they go public with that knowledge or not.
        • The organization is MILKING. They care as much about the long term interests of the company as Enron did.

          They are focused on making their service instrumental to their client's checking process; why else would they LIE about the capabilities of their service, and use insurance as some kind of quality assurance? Its perfectly obvious what they are doing.

          My prediction: "Office Guy" goes into bosses office, tells them their product isnt as secure as they say it is. Presents ideas for improving product. Ne

  • Good troll! (Score:3, Informative)

    by gazbo (517111) on Wednesday October 22, 2003 @06:01PM (#7285022)
    So you're a junior developer, you admit to knowing nothing about security, your company's sales are based mainly around its security, and yet you just...know that actually it's insecure.

    You even admit to not knowing where it is insecure, or what needs to be addressed in order to secure it. This is a beautiful troll.

  • Hmmmm.... (Score:5, Funny)

    by zulux (112259) on Wednesday October 22, 2003 @06:05PM (#7285054) Homepage Journal
    You're an underpaid jr. developer....

    Your company makes check writing software.....

    You want to show them that their software is insecure....

    Your Poor. They have checks. Things are insecure.....

    Hmm....

    • by Anonymous Coward
      You obviously haven't been around Slashdot very long, since you missed the obligatory numbering scheme:

      1. You're an underpaid jr. developer....

      2. Your company makes check writing software.....

      3. You want to show them that their software is insecure....

      4. Your Poor. They have checks. Things are insecure.....

      5. ???

      6. Profit!
  • by MerlynEmrys67 (583469) on Wednesday October 22, 2003 @06:08PM (#7285081)
    As a customer, I use your software - if there is a vulnerability, your company comes back in and reimburses my costs for the vulnerability... Sounds perfectly secure to me ?

    Go and write a million lines of security software and don't provide the guarantee - it isn't worth as much to the customer.

    What you have to realize is that it is an easy equation for your company

    How many reimbursements do they have to pay out on an annual basis. vs. How much will it cost to lower that number.

    I am betting they are paying out pretty close to 0 in reimbursements (which is why they are advertising this)- how much of your salary will it take to make the product even slightly more secure ?

    • I am betting they are paying out pretty close to 0 in reimbursements (which is why they are advertising this)- how much of your salary will it take to make the product even slightly more secure ?

      How long will the company stay in existence to pay this poor guy's salary if someone discovers and exploits the vulnerability? Do they have the cash reserves to pay off these reimbursements if they start coming in, or will they just fold into bankruptcy?
      • Bankruptcy all the way bay-bee!
        Just like those companies that make el cheapo hardware with a lifetime warranty. Warranty's useless if the company goes away!
        Then reincorporate under a slightly different name (maybe in a different state), tell all the customers that haven't had problems that you had a corporate restructuring and please update the name in their records.
        Et voila'! Yer back in business for the cost of a couple hundred dollars in filing fees...
    • Even though the security through obscurity has taken a beating, I think what the poster says is true. Even thpough the software may not be that secure, if the company doesnot derive any value from it, then they would not invest money to write ultra secure software. You have to remember that its the 'managers' who make the decisions, and they look at roi, feasibility...blah blah...So the way out would be for you to write the ultra secure software and also write an exploit for the existing software and hope
  • Just forget it (Score:2, Insightful)

    by crstophr (529410)
    Why rock the boat in this economy? You could be fired just because you pissed someone off. It's not worth the risk. Be happy you're working! I know it really bothers you, but not as much as missing those paychecks will. If you really need to, create one simple, nicely worded email outlining your concerns, and send it to the manager in charge. Keep a copy for youself. If in the future something does happen you can say, "see, I tried to warn you but you didn't listen. Here are my ideas for preventing
    • That's a great way to move up the corporate ladder - sit on your ass, do exactly what you're told, and never EVER take some initiative on your own.

      Wow, are you available to work? I'd LOVE to hire you!

      Looking out for the company's best interests, outside of your own small role, shows that you are interested in the company doing well and, even if nothing comes of it, will help when promotion time comes around.

      • Looking out for the company's best interests, outside of your own small role, shows that you are interested in the company doing well and, even if nothing comes of it, will help when promotion time comes around.

        Sadly, this isn't the reality in many companies. In my experience, initiative may be encouraged on paper, but it's frequently discouraged by culture.

        Many security problems are known, but are ignored for political reasons. The person ignoring the problem may very well be your supervisor, or an entr
    • Re:Just forget it (Score:5, Informative)

      by mikehoskins (177074) on Wednesday October 22, 2003 @06:36PM (#7285302)
      I think this is the best response I read.

      One thing to remember, you are a junior developer and you will rock the boat if you are not walking-on-eggshells-careful. This is true even in a good economy.

      Trust me, I used to rant about things broken in IT. I was respected for having a lot of knowledge and insight in IT. However much I still believe I was right, I learned, years later that attitude and patience will pay off more than brilliant ideas.

      An old saying has to do with attracting flies with honey. Learn that and learn all you can about security on your spare time, to buttress your claims. Show them how good and knowledgable a worker you are, to convince them your opinion is valid.

      Don't tell them they are wrong. Just factually show them how they could improve.

      (I wrote this in about 3 minutes, so if it doesn't appear coherent, read it again, without mentally spell checking and grammar checking. Sorry about the clutter.)
      • I think there's a big difference between not saying anything about the situation and educating yourself enough so that you can present your concern with some form of tact. I wouldn't suggest he shut his mouth and ignore it - that's not a good way to advance in the company. He shouldn't proudly yell about how stupid they are for having an insecure product but should instead bring up his concern as a question. It's all in how you bring it up as to how you are received BUT bringing it up is good for one's care
      • Re:Just forget it (Score:1, Insightful)

        by Anonymous Coward
        A side bar for this. I was working on for a parts distribution company. The software used locking so that someone left an order open with spark plugs and went to luch within 1 hour every Sales persons computer was locked waiting for this one person to come back and complete or cancel their order.

        I outlined the faults in a less than subtle way to the GM with general solutions on how to solve this (pick what you lock, update and subtract, etc). I was fired within the week.

        6 months later I read of a milli
  • learn how to hack (Score:3, Interesting)

    by aoteoroa (596031) on Wednesday October 22, 2003 @06:21PM (#7285188)
    Now I am no expert on hacking or security but I once read a book that changed the way that I write software. Hacking Exposed [amazon.com] taught me a number of different methods that can be used to find weaknesses in software. Once I learned some of the attacks that people could use against my applications fortifying against those attacks became much easier.

    Java Cryptography [amazon.com] was another informative read.
  • On the Internet, inside information is currency, and there will always be counterfeiters among us.
    -- J. Michael Straczynski
  • Art of the Steal (Score:3, Interesting)

    by mvance (75821) on Wednesday October 22, 2003 @06:50PM (#7285427)
    I recently listened to the audio book version of Frank Abagnale's "Art of the Steal" and I would definitely recommend it in your case. Like his other book, "Catch Me If You Can", it has some great anecdotes about cons. It even has a whole section devoted to check fraud.

    "Art of the Steal" aims to teach how to avoid getting scammed, in business and at home. It is definitely lacking in some areas, such as computer security, but does offer some useful advice and it might be handy in opening management's eyes to some of the threats to security.
  • If you tell them the truth, they will fire you. You work for buttheads. If you work really, really hard, they will not be sued for their stupidity. Of course that assumes they don't fire you.

    Why do you care? Shut up! Take your wages. If that bothers you, find a new job.

    PS - if you do talk to your boss and you do get fired, how many years will you be out of work while he's still being paid his salary. think about it - who hires a sysadmin fired for security concerns.
    • IANAL but I don't think that's as much of a problem as it appears..

      1) Your company's software is insecure (neglegence)

      2) They tell their clients it *is* secure (fraudulent advertising)

      3) You know about it (blackmail)
  • No seriously, after you are hacked a few times you start to learn about security and if you are like most people you become parinoid about it.
  • Security is not just a thing that software has or doesn't have. In order for us to answer this question, you need to tell us what you do and don't want people to be doing. How well the software addresses that distinction is what a specific instance of "secure" is.
  • If you are really concerned, read everything written by Bruce Schneier

    Applied Cryptography [amazon.com] will take you trhough the technical aspects of it, as well as presenting some of the attacks you can/might expect.

    Secrets and Lies is a more business focused book, and while it won't give you technical tools, the discussion on attack trees is a great intro to building a coherent security policy.

    The thing to remember about security is that it is an active process. In simplest terms: Put up an obstacle, identify w
  • Specifics (Score:5, Interesting)

    by greenhide (597777) <jordanslashdot&cvilleweekly,com> on Wednesday October 22, 2003 @07:13PM (#7285602)
    I cringe everytime I hear them say it, because I know that it is 'secure' only because of it's relative obscurity.

    By "obscurity", do you mean it's not a well known product?

    I'm going to jump out on a limb here and guess that if you're going around making check software, then someone in the company actually spent a number of minutes x (with x >> 5) thinking about security in the product.

    Here's an idea. You're a junior developer, right? Why not sidle up to a senior developer and say, "Hey, can we talk for a moment?" Tell them you've recently become interested in security and learning more about it. Ask them what the current security for your products is. If there isn't really any, ask them if they know if competitors use any kind of security features, saying something like, "I'll bet it would make our product look better if we could tell potential customers that we use x, y, and z to make our products secure." If he or she doesn't sound interested, evaluate how this makes you feel about working there. It probably isn't a good idea to make this a crusade; it'll just make you look mean spirited if you push through your senior developers. You can choose to stay in the company, knowing the product isn't fully secure, or if security is your thing, you can move to a company that's more secure.

    Think about a worst case scenario: someone writes a series of checks that are bad. That's not impossible to happen with normal non-computer generated checks anyways. It could potentially be a lot of money -- perhaps -- but credit card fraud is generally a lot easier to perpetuate. Most check fraud that does occur is people writing big checks on their own accounts that bounce, or it's people just forging checks, neither which you or your company have any part in.

    If you were in a company storing electronic medical records or bank accounts, then security through obscurity would be pretty catastrophic. But I'm guessing that you're blowing this out of proportion.
    • Most check fraud that does occur is people writing big checks on their own accounts that bounce, or it's people just forging checks, neither which you or your company have any part in.

      I investigate fraud for a major bank. The vast majority ( > 75%) of cases we get are counterfeit check cases. It is extremely easy to create checks that almost any retail store will accept.

  • Do you have a friend (or trusted FOAF) that could potentially be purchasing the software?

    Talk with him about what sort of questions to ask the salesman, and possible resposnses to weasel replies. Do NOT divulge any trade secrets.

    Then have him call up to get a sales pitch.

    A salesman bitching to management about a lost sale because of lousy security may be listened to more than a tech.
  • Do your homework (Score:5, Informative)

    by swillden (191260) * <shawn-ds@willden.org> on Wednesday October 22, 2003 @07:31PM (#7285750) Homepage Journal

    Developers, especially young ones, often see things that they think need to be changed, and get frustrated when management seems to ignore their concerns. In many cases, the techies are actually right, but they don't understand that (a) there are many, many issues to be considered that they don't know about and (b) simply claiming that a problem exists isn't enough. You also have to communicate the problem and its solution clearly and effectively, without rocking the boat.

    The solution in all cases, not just in issues of security, is to do your homework. When presented with a thoughtful, detailed, documented analysis of a problem, its potential *business* impacts, and a recommended solution, managers generally do take note.

    In this case, if you really care about the issue, there are some things you can do that will almost guarantee that you'll be listened to:

    First, you need to both educate yourself and construct and analyze a threat model. The "education" in question is more about business and risk analysis than, say buffer overflows and leaky protocols, and the process of building and analyzing the threat model will give you a lot of it.

    A threat model generally consists of the following major areas:

    • Potential attackers. Identify and document all of the categories of people who might wish to attack the system. For each potential type of attacker, outline as thoroughly as you can the attacker's motivations, access to the system, capabilities and tolerance for risk.
    • Risks. Identify and document all the kinds of risk to your company's *business* that you can think of. Are there any ways an exploitable system could cause direct financial losses? What about damage to the company's reputation? In the event of an exploit, will the company be financially liable? This means you also need to explore and document risks to your company's customers.
    • Avenues of attack. Identify and document all of the different ways in which the system could be attacked. You don't need to identify particular weaknesses, just categories of weaknesses. Be sure that you don't focus solely on technically-oriented attacks. If there's an easy-to-perform, hard-to-trace non-technical attack that no one is bothering to exploit, it's very unlikely that an attacker will bother with trying to break the technology.

    After you've created the threat model, you need to analyze it. To do that, you need to try to quantify all of the elements of the model. In the business world that ultimately comes down to assigning dollar values to everything. For each attacker, try to figure out how much they could steal by attacking the system. Even harder, try to quantify the value of attacks for ideological reasons (if any). For each risk, quanitfy how much the company stands to lose if the risky situation happens. For each avenue of attack, try to quantify the cost of performing the attack.

    Once you have dollar values for everything (many will have to be expressed as ranges, and all will be built on guesswork), look to see if there is any combination of motivated attacker, risk and avenue that looks like a "good attack". That's an attack in which it's in the attacker's best interest to perform the attack, taking into consideration the possible negative effects as well as the benefits, the attacker's motivates, access, resources, etc.

    Think long and hard about all of the good attacks, try to assign probabilities to them based on everything you've learned (plus another crapload of guesses, of course) and you should able to come up with an expected cost for each of them.

    The last stage of the analysis is to try to guess at the cost of fixing them. Don't even bother trying to think about financial "benefits" of fixing them... "You can tell all the customers that its *really* secure!" doesn't mean much because they can *already* tell the customers that. It may not be true, but you're wandering into marketing, where truth is... flexible.

    You're not

  • I know that it is 'secure' only because of it's relative obscurity.
    I personally know very little about security
    Lemme get this straight. You "personally know very little about security" and you claim that the app is insecure? Perhaps I should declare I know little about auto maintenance but I'm certain that my car is going to blow up the next time I drive it!
    • This seems to be a source of contention. Perhaps I should expand a bit...

      I played around with a cracking tutorial a while back. I applied the concepts in the tutorial to our product. It took me all of five minutes to crack the activation scheme.

      Out of boredom, one day I decided to try and break through our encryption (this was before I became a developer). Turns out its a simple byte-shifting algorythm.

      So, I know very little. That's enough to recognize weaknesses, but not exactly enough to come up with a
      • Nicely clarified. Thanks.
      • Out of boredom, one day I decided to try and break through our encryption. Turns out its a simple byte-shifting algorythm.

        You should have explained that earlier. This makes a big difference. You're now faced with a dilemna. Make stink and risk your job, or keep your head low and don't make waves. The middle road of bringing the issue up in a job-safe manner is tricky. You know more about your company's internal politics than I do.

        At my company I replaced the security on an embedded system. The old method
  • Just tell us what company this is. Leave the rest to the /. crowd.
  • Perhaps its not a great idea to be working at a financial company, and go about broadcasting your insecurities and saying you dont know much about security.

    Good thing your email address is from a yahoo domain.

    It still might just be possible that the cost of hiring security specialists/developers in the long term is more costly than paying through insurance the very occasional mishap.

    And as you mentioned it is a check printing app. The one we use just runs in a windows2000 server and prints to a network d
  • Even if the product has more holes than swiss cheese, they will say it is secure because that's a popular sales buzzword. The truth is irrelevant, just tell people what they want to hear, and take their money. That's how Microsoft does it. All they will ever care about is moving the merchandise, and you can't change that. I know it is hard when you care about what you do, but you need to find a way to accept that you only work there, and it is their problem, not yours.
  • You say they're selling "security insurance"? That may be your line of attack. If it's "insurance" then there probably has to be an underwriter. (If they're doing it on a wholly self-insured basis, they probably still have regulatory issues to deal with. Of course, IANAL, YMMV, warranty limited to the cost of electrons used.)

    Now, the way insurance works is that someone computes the risk, defined by the equation

    R = P H

    where R is the risk, P is the probability of the undesirable event, and H is t

  • 1) Find a check printing software house with poor security on software
    2) Get hired
    3) Print checks bypassing the poor security
    4) Profit!
  • Dude, I've been in your shoes. Straight out of college, financial software company that might have printed checks, scared to death that 'security' meant changing the attributes on the plain-text username/password files to hidden+system. Your situation will be different, because I"m sure they're not the same company (the one I worked for has been bought and sold several times since I was there, so it's not the same at all). But here's what I did: 1. Analyze the threat. Figure out how some one could get

If you do something right once, someone will ask you to do it again.

Working...