Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Security in business apps

By jacob in Op-Ed
Thu Oct 26, 2000 at 06:13:22 AM EST
Tags: Security (all tags)
Security

It would seem obvious that programs that cost businesses tens or hundreds of thousands of dollars or more would have way more time, energy, and expertise put into them than $50 programs you find at CompUSA, right? They would certainly be designed by teams of quality at least comparable to the quality of the people who design free software as a labor of love, it would seem. Well, my recent experience has shown me that isn't quite true. Particularly in the realm of security, I found that some business-application developers released code that any self-respecting programmer would be embarassed to give away for free.

And here's the kicker- people are buying their programs.


Recently, I worked for the first time in what would be considered a business environment: I was a support person for an IT department that purchased and deployed business applications from third-party vendors. While I was there, I was appalled by how absolutely clueless the vendors from whom we bought applications were about even the most basic security concepts. For example, one product we purchased required its own special usernames and passwords. It kept each username/password pair in a database table with passwords encrypted. However, it took my coworker and me about thirty minutes to deduce that the encryption function merely applied a one-to-one map on each character and then reversed the resulting string, making its cryptographic function easily crackable by anyone with a Captain Midnight Decoder Ring. Even worse, the password file didn't have the 'root'-level username and password: those were hard coded into the binary, the source to which we did not own and did not have access to. When we contacted the vendor, they were surprised that we would think of these things as problems, and they never provided us a patch, even though we explained to them what the MD5 hashing algorithm was and gave them a URL for a sample implementation. I honestly don't think they realized that there was anything wrong with their password scheme.

Horror stories like that one abounded. Here are a few more examples: The vendor of one of our other main applications delivered a web front-end that did absolutely all of its data verification in javascript on the client's web browser, and when I pointed out to them the sheer insanity of that approach, tried to convince me that it would be okay if we could disable source viewing on the clients. That same product also invented its own encryption scheme in which the ciphertext was a linear combination of the plaintext and the secret key- I'm not a cryptologist, but I did just fine in algebra in eighth grade so I was able to break that one without much problem. It also exposed to the Internet functions that would update arbitrary table fields for anybody who knew how to name them, not because the functions had bugs that a cracker could exploit, but because that's what they were built to do. They had names like update_value(field, new_value) and they had to be exposed to everyone who used the web front-end or the front-end wouldn't work.

I mention these things for two reasons. One, because I wanted to rant about how clueless the vendors I worked with were about security. It's not as though these were particularly challenging security problems, like format string attacks or buffer overflows- vendors shouldn't ship products with those flaws either, but it's at least understandable how one or two could slip under the radar of a busy development team. The errors that were common in the programs I had to use should never be made by anyone. Two, I wanted to ask the kuro5hin community how typical my experience was. Is the closed-source business application world all like this, with clueless companies selling products that the CEO's twelve-year-old kid could crack with no trouble? Or did I just have bad luck? If I'm not alone in my experience, what (if anything) do you think should be done to make the bad developers stop releasing horrible code?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Kuro5hin
o Also by jacob


Display: Sort:
Security in business apps | 61 comments (61 topical, editorial, 0 hidden)
Side-effect of cheap and/or young programmers (4.30 / 33) (#1)
by katravax on Thu Oct 26, 2000 at 02:45:03 AM EST

We hear about age-discrimination and the like in hiring for IT departments, and how one of the effects of that is projects do not benefit from having older, more experienced programmers. I beleive what you're witnessing is a side-effect of that practice. The only reason to implement security in JavaScript like you describe is because that's the only language the person knows. There could be no other explanation for it. I have seen so many green programmers that are good at a particular language, but are clueless to the big picture, and that not every nail should get the same hammer.

In general, younger programmers get in a hurry to get the task done because that's the sort of mode they're put in by brainless management, as well as the natural tendency of youth. Rather than slow down to consider several ideas and the good/bad points of each, they rush to code the first thing that occurs to them. Also in general, younger programmers are not the type that do security programming... thus the problem is compounded by lack of knowlege in addition to lack of experience.

As a point of example, in my office, all portions of all applications are up for discussion. Especially in the design phase, a topic will be brought to the group with suggestions for ideas on how to handle it. Each method will be discussed along with the good and bad points as they occur to us, and then several methods will be coded and tested. Once we find the winner, it's re-coded to be the best it can be. However, it doesn't stop there. At any point in the future, should we find a better way to do the task, it is rediscussed.

What does this have to do with security? We're not in a blind rush to get a piece done like at some companies. We know that planning ahead and careful testing don't actually put you behind schedule, but actually eliminate problems in the long run, and can shorten the schedule. Thus, security, like other portions, is given the go-round. Also, we don't hire young-twenty-somethings to work long hours for lower pay... so we don't pollute the waters with impatience in design and programming.

What you're seeing in the applications with terrible security, plain and simple, is lack of knowlege combined with impatience and inexperience. In other words, precisely the type of programmers that management seeks out because they're too hungry to demand better for themselves, and demand better of the applications they're working on. So no, you're not alone, and no, your experience is not atypical. Security sucks in most programs, as well as usually every other facet of those programs. Shitware reigns supreme, because by and large, the customer doesn't demand quality, and management and programmers aren't skilled enough to produce it anyway.

Disclaimer: I am a programmer who is absolutely fed up with bad security, bad design, and bad applications in general. I point the finger squarely at my own profession.



I mostly agree, but... (3.50 / 8) (#7)
by pb on Thu Oct 26, 2000 at 04:23:45 AM EST

I think I see where you're coming from, but I have to object to the age factor. There's no reason why someone can't get into programming later in life and be equally (or moreso) incompetent than a younger programmer, (who perhaps has been programming for half his life already) so I think that experience and exposure have more to do with this. You already basically mentioned this, but I still object to the ranting about young programmers.

Also, making people work long hours for low pay is a recipe for disaster in the first place. Make sure that your staff is well-trained, rested, and satisfied with their job insofar as that is possible, because that will help you much more than a 30-hour workday will.

Disclaimer: I'm a programmer, I'm 22, and I don't think that should matter. Since I can produce code, you can judge me on the merits of that instead. :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Excellent Post! (3.25 / 8) (#8)
by Matrix on Thu Oct 26, 2000 at 07:29:40 AM EST

But its not really young programmers as such that are the problem. I've met quite a few young and old programmers in the past couple of years, and competence, while slightly rarer in the young programmers, was still present in both groups. Perhaps a better divider (as I think another reply mentioned) would be experience. Including taking a proper CS or math degree. Age discrimination might be a bad phrase for it. How about experience discrimination?

Another thing that's needed, is a well-thought-out design process. And people actually considering things brought up by the design team.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Not entirely (2.50 / 6) (#12)
by Quark on Thu Oct 26, 2000 at 08:45:08 AM EST

Perhaps a better divider (as I think another reply mentioned) would be experience.

Please note that while I'm not disagreing with you, I'm of the opinion that by far the most important virtue of every type of employee is attitude. The plain fact that someone wants to do his job as good as possible will provide so much progress in a short time. A certain type of working environment is required here, of course, but if you handle this kind of people correctly and give them what they need then you can do just about anything.

Perfectionism isn't always a bad thing, especially when it concerns coding.

So much bandwidth, so little time...
[ Parent ]
commitment (3.20 / 5) (#9)
by mstevens on Thu Oct 26, 2000 at 07:48:03 AM EST

I think the problem is whether people actually care about the quality of what they produce -- the only way to get better, more secure applications is to make people *care* if they produce something good, and do it to such a degree they look at a lot of details they could get away without working on, like documentation, and commenting, and writing good code, and security.

[ Parent ]
I'm getting really sick of management bashing (3.10 / 10) (#14)
by jayfoo2 on Thu Oct 26, 2000 at 09:51:16 AM EST

There are typically a lot of posts here and on /. regarding the cluelessness of management and how it leads to just about everything wrong in the world. How the valient programmers are struggling mightily to hold back the hords of marketriod mongols. It's bullshit.

Guess what. Some of us get it. Some of us know about security, and quality, and all sorts of neat stuff like that. Some of us understand that in business you sometimes have to make compromises. That if you wait to deliver a perfect product your competitors will be on version 4 with all your customers. We know it's not optimal, but if we don't compromise everyone loses their jobs (including the programmers).

I am so sick of the haughty superiority of programmers. Please remember that you are not the only smart people in the world.

If you want to know why programmers tend to get ignored in these kind of situations this is it. Senoir management tends to get pretty turned off by being called clueless.

To the person who wrote the original message I'd advocate spending more time in the business school. Learn to write, talk, and work with teams of people (who are often less smart than you). That's what the real world is like. Learn it now.

[ Parent ]
Then we're not talking about you (4.00 / 6) (#15)
by katravax on Thu Oct 26, 2000 at 10:43:14 AM EST

If you get it, then those comments don't apply to you. However, if you believe that all, or even most of management is competent in managing software products, then you're sorely mistaken. It's not about who's the smartest or who wants to sell products, it's about managers that through lack of understanding and especially too much ego refuse to even listen to those with experience, and then run projects into the ground. I suppose you can conveniently ignore the fact that 90% of software projects never ship.

I've seen programmers that had bad reviews (mostly for "attitude" and "teamwork issues") and that have been fingered for poorly turned-out projects. They then go on to other companies and succeed wildly. So if that isn't management's fault, whose is it?

This is an aside from the original discussion on security, but it is a good discussion nonetheless. If you and your cadre don't have these problems, then we're not talking about you. The proof of bad management is that there is a quantity of good management, and the fact is, we know the difference. Instead of wanting your workers to understand you, as management the job is to understand, motivate, and manage your workers. You need to comprehend that distinction. It is your job to manage, not whine and seek sympathy.



[ Parent ]
good point's but... (3.50 / 4) (#21)
by jayfoo2 on Thu Oct 26, 2000 at 11:43:00 AM EST

Let's just remember that it does take two to tango. You're right, it is the responisbility of management to motivate, direct, and encourage workers. However do you ever notice that it is not always the coder with the strongest kung-foo that gets ahead?

For very good reasons our society places value on the ability to communicate and work with people.

I love people who are quality focused. I love people who are passionate about their work. As a manager I have to work with people who are team players and those who are more difficult. I'm going to motivate and encourage all of them cause I need them to meet their objectives. But who do you think I'm going to ask for on the next cool project. Who do you think I'm going to be an advocate for to senior management. Who do you think I'm going to try to get the bigger raises for.

I'm not saying that it's all programmers fault and management has no responisbility. I'm saying that you as programmers can help yourselves out greatly by not copping attitude.

[ Parent ]
I can't disagree with that (3.00 / 3) (#27)
by katravax on Thu Oct 26, 2000 at 12:56:21 PM EST

Note in my original post I pointed the finger at programmers for the problems. I cannot disagree with the statement that programmers make their own problems much of the time. It's usually ego ("attitude") that causes the problems, which interestingly enough, is the same thing that causes managers to screw up some times. People often take things personally and put up a defensive shell rather than learning and improving. Please let me clarify that I am not anti-management. I am anti- bad management, the same as I'm anti- bad programming.

[ Parent ]

Thankless job (3.50 / 4) (#30)
by bjrubble on Thu Oct 26, 2000 at 02:20:14 PM EST

I currently have a great manager. And you will never (except for right now) hear about it. Sorry, management is only really visible when it's bad; good management for me means that I always have useful things to work on and achievable timelines to work in. That ends up translating into the main job of my manager being shielding me from his management and the potential idiocy generated there. When I think about it, I really appreciate it, but I just notice being exposed to horrible idiocy more than being shielded from it. That, and good managers are rarely the source of funny stories.

[ Parent ]
Overthrow Capitalism (1.00 / 1) (#49)
by DefCon on Fri Oct 27, 2000 at 09:41:52 AM EST

If you want to know why programmers tend to get ignored in these kind of situations this is it. Senoir management tends to get pretty turned off by being called clueless.

Sure they get turned off, coz it's the truth. They are clueless, and they should be working for the programmers, not the other way around. If it wasn't for their greed constantly fucking up our work and turning projects into rat races, we might be able to get some decent work done for a change.

[ Parent ]

Poor you (2.00 / 1) (#58)
by needless on Sun Oct 29, 2000 at 06:52:05 PM EST

Oh, mourn for the managers... Those battle hardened souls that get paid more for doing less work. Face it, your job (in any field) is simply to organize and occasionally crack the whip to get things done. The only time you have to really do the work is when you're very shorthanded (usually because someone is fired/laid off/etc by a manager).

The very idea of management is that your employees are too incompetent to handle themselves and make decisions, and you wonder why you are universally reviled? If employees are incapable of handling themselves then you hired the wrong people.



[ Parent ]
Inexperience vs. Youth (4.62 / 8) (#19)
by katravax on Thu Oct 26, 2000 at 11:11:32 AM EST

Several posters have rightly commented on my pointing out that part of the problem is often young programmers, and suggested that the problem is really inexperience, not youth. One even pointed out that a degree in computer science or mathematics is to some degree a proof of knowlege and competence. I must adamantly state this is not so. In fact, by and large, we find that most recent comp-sci grads are 1) worse programmers than most in the profession that don't have a comp-sci degree and 2) think they know it all when they barely have a grasp. I am not saying all comp-sci grads are like this, but I am definitely stating that many are.

The company I work for doesn't discriminate against young programmers. We discriminate against those that think they know everything and thus refuse to listen to experience and refuse to learn anything. They think that 4 years of academic programming and algorithms qualifies them to do anything. Their code frequently proves otherwise. However, we're not a bunch of old guys at my company. I beleive the oldest programmer we have is 35. But I can guarantee you that age is not our deciding factor. Besides, I was demonstrating a point about how it is in my company, not speaking as an official representative thereof. One of our goals is to produce the best product we're capable of, and that often entails learning new subjects (such as security) from ground zero.

The fact is, many young programmers, because they are highly-skilled in a particular area, think they are experts in general. Usually they are not. I also agree with the point that there is no skill-level or knowlege difference between a young programmer and one who started later in life and happens to be older. The difference is that the young ones typically don't receive input well or really try to improve their skills. This changes after they've been on a few projects, but the company I work for is small enough that while we do have time for them to learn and experiment on a given topic, we don't have time to fight the ego and attitude common among many recent comp-sci grads. We pay extremely well and have top-notch benefits and almost never work more than 35-45 hours a week. Thus, we can afford to be choosy and pick the best that apply, because we get a lot of applications. It just so happens that rarely are the chosen applicants recent grads. It's that we choose the best for the position; we don't say "not him because he's young."



[ Parent ]
Can I work for you? :-) (3.25 / 4) (#34)
by molo on Thu Oct 26, 2000 at 04:39:59 PM EST

You just explained my ideal work environment. But yes, I will be fresh out of school in May. However, my school requires a co-op program for some majors (including CS), where we actually have to go out and work on real-world problems and projects. Its a valuable experience and I think it doesn't produce people that are as academic or overconfident as most.

Anyway, I will soon be trying to find a good job, and I have to figure out how to go about weeding out employers that are brain dead and trying to figure out which are keepers. Can anyone give some advice?

--
Whenever you walk by a computer and see someone using pico, be kind. Pause for a second and remind yourself that: "There, but for the grace of God, go I." -- Harley Hahn
[ Parent ]

I wish I could (3.25 / 4) (#46)
by katravax on Thu Oct 26, 2000 at 10:12:48 PM EST

I'm not saying this to be rude, but I wish I did have advice. I've worked at some truly awful hellholes, and nearly didn't take my current job. I passed on a standing invitation for three months because I was nervous about leaving a good place to work (my prior job, while with it's occasional crap, was still a good place to work). When I finally accepted the invitation for my current place, I was amazed to discover it as the panacea it is.

I totally lucked into my current job. I took jobs in the past that I thought would be great, and were degrading and cruel once I was there. I guess the only advice I picked up was to keep trying until you're happy somewhere. I'm fortunate the place I'm at considers our happiness and satisfaction as a primary goal. We're also the most motivated and hard-working group I've ever seen because the bosses treat us so well. We've accomplished some truly world-class stuff because we're treated so well, and we want the company to do well in return. I guess you could say the company treats our personal goals as important and we treat its as important. Ever worked somewhere where every single employee was happy to be there and knocked themselves out to do the best job they could? Me neither until this job.



[ Parent ]
the education system (4.28 / 21) (#2)
by jesterzog on Thu Oct 26, 2000 at 02:45:15 AM EST

At the university I attend there are two factions of computer/IT education. One of them is the school of mathematical and computer sciences (part of the science faculty), and the other one is the school of communications and information management which is part of the commerce faculty. I've been completing a joint degree with majors in both of them. In theory they both aim towards crossovers in the same types of job, but there have been major differences in the teaching philosophies.

The science degree is brilliant, but I don't think I've learnt anything useful from the commerce school at all. 75% of it is repetitive babble about entering the "information age". One entire lecture was about how to get a shadow effect behind a label in an MS Access form by using two labels and making the front one transparent. In another course, they teach web design but don't actually teach people how to write html or any of the theory behind the language. As long as everyone knows all the cool commercial things you can do on websites, you're expected to work out how to do it on your own for handing in projects.

I heard a story from someone in a different yeargroup where they were doing group programming projects, but the groups had to be organised so there was one computer science student in each, because the info people don't actually teach programming. (Apparently you're supposed to pick it up through online help.) In the end our projects weren't actually marked on doing what the specifications required - they were marked on having all the buttons lined up exactly in the demonstration. I could go on but it'd just be more of a pointless rant than it is already.

Anyway, I think the problem is that the commerce people are trying to just teach what businesses say they want. The dilemma is that businesses don't really know what they want - they just want stuff that looks like it works, but don't know how to specify how it should work. The result is that many institutions train up a bunch of Microsoft drones with "skills" that will be mostly useless in 3 years. (For the record, I'm not meaning to flame Microsoft specifically with this comment.)

This is the type of education that doesn't really teach people about security. Instead it teaches people how to install a product that claims to be secure, and it teaches people how to hack together VBA scripts to make buttons do things that are useful. Yet it's the same qualification that a lot of people get before walking into the IT world. I don't think this problem will go away as long as educational institutions are indiscriminately letting businesses dictate what they teach.


jesterzog Fight the light


Full disclosure? (4.15 / 20) (#3)
by Miniluv on Thu Oct 26, 2000 at 03:35:14 AM EST

Have these products appeared on bugtraq? Have you written sample exploits for these applications? Have you pressured the vendors to provide patches with the knowledge that if they don't you will release exploits into the wild?

These are the tactics that cause vendors to fix these bugs. Microsoft responded to bugtraq, Sun responds to bugtraq, virtually every major vendor does. These days they cannot afford to. Every hacker reads it, virtually every admin is subscribed, and tons of people who aren't either are just for the fun of it.

I appreciate your frustration, security in programming still isn't being taught the way it should be. Part of it is the fact that folks who write code to give away do it for fun, and take pride in their work. People who write code for a living have the opportunity for different motivations. Many of them are prideful people who write the best possible code because they CAN, others are not. Some of these people see it as a 9 to 5 daily grind with a somewhat higher salary, and their code shows it.

Ultimately, as a user base we are responsible for exercising our consumer powers, and in the security world this means full disclosure. It means finding those bugs, writing proof of concept exploits, and letting the world know the bug exists. For an interesting read on how to go about this process, check out Rain Forest Puppy's draft proposal for a method of contacting vendors while practicing full disclosure.
"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'

What *were* these products? (3.52 / 17) (#4)
by streetlawyer on Thu Oct 26, 2000 at 03:40:18 AM EST

It's impossible to tell how much one should care about these security flaws without knowing what kind of products they were. I've got a website with password protection for some of my clients, and I store all the userids and passwords in plaintext in a database. Why? Because I don't really give a fuck about security on that website. I just want to have a password screen up there so that anyone getting into my site has to look at and accept my disclaimer. Plus, I want to track what my clients are looking at so I can tell what they're interested in. If someone hacks my password database, then whoop de do -- he'll have access for free to the same information that he could probably have got anyway by giving me a phone call.

Security is all about fitness for purpose -- without knowing the purpose, we can't contextualise this rant.

--
Just because things have been nonergodic so far, doesn't mean that they'll be nonergodic forever
RE: What *were* these products? (4.50 / 6) (#5)
by kjeldar on Thu Oct 26, 2000 at 04:11:28 AM EST

Why? Because I don't really give a fuck about security on that website. I just want to have a password screen up there so that anyone getting into my site has to look at and accept my disclaimer.

If someone hacks my password database, then whoop de do -- he'll have access for free to the same information that he could probably have got anyway by giving me a phone call.

Suppose one of your site users is a moron and uses a valuable password (i.e. root, enable, K5 account, whatever) as your website's password. I doubt you would feel too bad for the poor schmuck, but the possibility remains nonetheless. It seems a large part of IT these days is protecting idiots from themselves.



[ Parent ]
The nature of the products... (4.50 / 4) (#20)
by jacob on Thu Oct 26, 2000 at 11:40:51 AM EST

The first was a not-terribly-important app, but one that would have several non-technical users logging on and setting passwords that could potentially be the same as their more valuable ones. With that app, I would have been satisfied had they just had no encryption at all and let people know that (well, except for the whole hard-coded unchangeable password thing, which is unacceptable anywhere ever in my book). But what is the point of a bad encryption scheme? It just gives the deployers a false sense of the security of the program.

The second app was quite important, and the linear equation encryption scheme was protecting our most important database's integrity. Those people, at least, listened to me when I told them their program's encryption was worthless. But why didn't they know that in the first place? Why is it my responsibility as a user to catch and point out that their program as basic technical flaws?



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Heh... (3.40 / 15) (#6)
by pb on Thu Oct 26, 2000 at 04:13:23 AM EST

I'm sure your experiences are pretty typical of what's out there, actually.

I've seen major programs attempt to hide text in the binaries with good ol' XOR, (when they attempted anything at all...) which was readily broken by XOR'ing the original string (displayed at startup) onto the "encrypted" string, and easily altered afterwards by writing a program that XOR'ed an arbitrary string onto the (now not-so-secret) "password", and pasting that part back into the binary.

Just because a programmer is supposed to implement an arbitrary feature doesn't mean he's an expert in the field, or knows anything about security. Or maybe he knows it's broken, but either didn't write it originally, doesn't have time to fix it, has a spec written by chimpanzees, morons, and business majors, or all of the above. Who knows?

But yes, in cases like this, I'd want some peer review or disclosure. That's why things like BugTraq and Open Source are very good things. Otherwise, your expensive enterprise system might be toast after 5 minutes with a hex editor.....
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
Do you one better (3.00 / 1) (#29)
by Biff Cool on Thu Oct 26, 2000 at 01:59:28 PM EST

We're using some software that requires a login/password sent to the company's server, they require the password be sent encrypted (simple XOR). But it's not encrypted by their software, and the transmission isn't encrypted, the XOR'd version of the password is stored in the config file. We may as well be sending the password in plaintext (we are for all intents and purposes) since nothing else is encrypted.

My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
You ain't seen nothing! (3.00 / 17) (#10)
by Dacta on Thu Oct 26, 2000 at 07:50:33 AM EST

I know of a company (who shall remain nameless) who were developing an application for an industry which has access to huge amounts of very private personal data, which this application would manage.

There was serious discussion about embedding the Internet Exploror webbrowser control into the application, so that the companies using that application could make money by showing banner ads to their employees. Given the large number of security holes in all web browsers, I was concerned, to put it mildly!

Yes, I'm serious - they really wanted to do this.

The only reason it didn't happen was because deadlines were too short.



Some thoughts, some questions (3.07 / 14) (#11)
by farmgeek on Thu Oct 26, 2000 at 08:19:03 AM EST

Reading your post I kept wondering who these vendors are? Are they major vendors (MS, SUN, ETC) or are they the specialized type of vendors that we have to deal with (three guys in a shack Inc.)?

The reason I ask, is that a lot of the specialized applications are not really put together by programmers. They are put together by some people working in a business that has some need. They may have thrown together something using whatever tools they had at hand (MS Access Payroll Apps) and solved their problem. Then they begin to see a widespread need for this solution and so try and beef up what they have a little and sell it.

They're scratching an itch. Also, if security is a consideration for your company, why are you buying this stuff to start with? Tell the vendor that their product does something you need it to, but that you need better security before you can buy it.

I realize the purchasing may be out of your hands, but take the time to point out the security holes and their possible consequences on your boss's job security and you may get some results. If not, at least your boss will know that you're knowlegable and might bother to ask you next time BEFORE a decision is made.

Everybody "takes security very seriously" (4.00 / 1) (#42)
by swr on Thu Oct 26, 2000 at 07:17:02 PM EST

Tell the vendor that their product does something you need it to, but that you need better security before you can buy it.

You'll probably get a response along the lines of, "we take security very seriously".

So how are you supposed to gauge the security of a software product? Do you really have time and expertise to do a proper security audit? Do you go over the source code? How effective is black-box testing where source is not available?

And when all is said and done, what have you accomplished? Usually security can only be proven in the negative. If you found a bunch of security problems then you know the program sucks. But knowing what software not to buy doesn't help much when you're trying to figure out what software you should buy. You can know that it sucks, or not know that it sucks, but you can't know that it doesn't suck. If you haven't found problems maybe you just haven't looked in the right place. At best you can look at code and conclude that it was written by a security-concious person, but was all of the code written by the same person in the same mindset?

99% of the people out there can only take the vendor's word that "they take security very seriously". How many vendors really give a damn about the other 1%? Bugtraq helps a lot but the majority of software out there is custom work and never draws the attention of the bugtraq folk.



[ Parent ]
The companies (3.00 / 1) (#43)
by jacob on Thu Oct 26, 2000 at 07:30:41 PM EST

The companies I described were both small shops, but nonetheless shops that did nothing but write and sell the products that we purchased from them.

As for why we buy it: it has to do with what I mentioned in the article. The people who make the purchasing decisions don't have to actually deploy the software, and generally aren't technically-minded enough to realize a gaping security hole if it isn't explained to them slowly in little words. And from their perspective, the products are a total success (at least the first one, which we're using; the second vendor is currently rewriting the product I described for unrelated reasons). The higher-ups and end-users see a program that seems to work just fine, and they don't think of the huge design flaws in the program as anything more than technical quibbles.



--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Charging money for a steaming pile of doo-doo (2.00 / 21) (#13)
by Ethelthefrog on Thu Oct 26, 2000 at 08:46:59 AM EST

The principal reason I dispise Microsoft and all that it stands for is not closed standards, embrace and extend, or any of the relatively recent threats. The reason is that they have made it socially acceptable for a company to ship a product that just doesn't work, and charge money for it.

It's a sad state of affairs and it seems that other software vendors have decided that is the way forward.

Vive la resistance.

Ethel.

I disgree (3.00 / 3) (#28)
by ChannelX on Thu Oct 26, 2000 at 01:02:43 PM EST

Only part of the blame can be placed on any software vendor. The buying public are the ones that deserve most of the blame. Why should Microsoft improve anything if the public accepts what they produce without question? If people complained much more than they currently are things might change.

[ Parent ]
What will you tolerate? (3.00 / 1) (#53)
by chuq_r on Fri Oct 27, 2000 at 05:10:29 PM EST

Let me start off by saying that I agree with that sentiment. If people were pickier about the quality of the software they chose to buy, that would probably improve matters greatly.

But I must point out that since people DON'T complain, many of them simply must not care about this problem that much, possibly not even viewing it as all that much of a problem and more of an unalterable reality. And from my own anecdotal experiences, I'd have to say that this assessment is fairly true. Their Macintosh crashes and they mumble about it but they reboot and go on like they can't do anything about it anyway. Office cost them $300 and they bitch a little bit about it, but next year they buy the upgrade for $120 because they "need to have it". This is 95% of computer users that I know.

There is a significant minority who really DO care, who don't like being charged money for empty promises of stability and security. These are the people who tend to enlist the help of people like me in making decisions and getting advice. But that's relatively few. Almost everyone else tolerates the crap and it's not Microsoft or Apple or IBM or anyone else's fault in whole; it's also their own fault. It doesn't take a CS major to see that there are always alternatives available, but most people lack the motivation or confidence to do anything but be held by the hand and charged $10 a mile for it.

That's just my take on it. Feel free to disagree. :)

Chuq

[ Parent ]

Sometimes the program isn't the problem... (3.60 / 10) (#16)
by flieghund on Thu Oct 26, 2000 at 10:48:59 AM EST

Sometimes it's the management policies of the company that compromise the program's security. Case in point: at my workplace, we have three programs where passwords are required:

  1. Windows (logon): password == username == firsname+lastinitial.
  2. Time Card: password == "password" (oooh).
  3. Telephone voicemail: password == "XXXX" where XXXX == employee number.

I have on occasion commented on just how silly it is to require passwords on the programs that are so incredibly obvious. Are they hoping anyone trying to break into the system is a complete retard and/or "too smart" to guess the obvious?

(And yes, I have tried to change my passwords, but the IT manager freaks out -- not because he cares, but because the higher-ups will yell at him if he lets us poor peons change anything. He already gets neverous as hell every time he looks at my desktop and sees how I've rearranged damn near everything to my suiting...)


Using a Macintosh is like picking your nose: everyone likes to do it, but no one will admit to it.
I've seen worse. (3.00 / 1) (#59)
by shippo on Fri Nov 03, 2000 at 08:36:46 AM EST

I spent a brief (though not brief enough) time working for one company. The main network consisted of a simple username (initials, I believe) and a blank password which could not be changed.

The purpose of this, I later discovered, was to allow the boss to read all staff's emails. As this was an internal email system, I've no idea what he wanted to acheive. I left the company the same day, disgusted with many of their practices.

[ Parent ]

This is one of the reasons I moved into QA (4.15 / 13) (#17)
by greyrat on Thu Oct 26, 2000 at 10:50:55 AM EST

I get to show the developers that XOR without even a 'salt' variable is not an acceptable password encrytion scheme. And that running ANYTHING exposed on the client side is a Very Bad Thing.

This is much more pervasive than just security. The whole concept of stopping to think about design seems to be missing at most development shops. If you want my suggestion for what you can do, here it is: If you see bad design, raise the issue IMMEDIATELY and LOUDLY. Yes, risk your status and perhaps even your job if you want to make it better.

In the end however, the big problem is the central dilema of doing QA right in the first place. That is -- lack of tangible payoff for avoiding the percieved risk. If you do QA right, there are no security (or other) problems. So, if we had no problems, why did we waste all that time on QA in the first place?

Welcome to my world.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

loud and clear (3.00 / 3) (#32)
by marisa on Thu Oct 26, 2000 at 02:57:18 PM EST

i agree completely with what you're saying, and apply it everyday at work.

what i think people are overlooking is that management can (and frequently does) destroy a product simply by pushing for an unreasonable deadline. they have to get it out, and they don't think security is a valid reason to delay that process (apparently, nor is quality). what i'm saying is that oftentimes it's not the developers fault at all, nor is it the fault of the qa team. people in many cases are doing excellent work in the time given, i hate seeing blame fall onto very capable programmers when in fact what they're doing is astounding given the restrictions.

-marisa
--
"Physics is not a religion. If it were,
we'd have a much easier time raising money."
[ Parent ]

Hail true QA (3.00 / 1) (#50)
by jabber on Fri Oct 27, 2000 at 10:44:12 AM EST

Where I work, QA does nothing more than harrass employees about the formatting of their documents and the location/revision of company stadards. Frankly, I'm embarassed to say that until I read your post, I thought that this was what QA was all about throughout the industry, and had the appropriate level of respect for the field.

I'm glad to see that there's a whole carde of people out there, whose task it is to do those things that I've been taking upon mysel - keeping me (as a designer/developer) honest in my implementation.

The organization where I work keeps close tabs on the effort put into tasks, and requires that timeframe estimates be as trim as possible. I'm sure you can image how difficult it is to submit a 'realistic' estimate for a piece of code, and get it approved. I'm sure you can imagine which items are made to be 'shelved', so a more 'efficient' estimate can be accepted - and the resulting code - and it's consequences on the reputation of the coder.

Management needs to stop planning based on an assumption of optimality. 80% of the work can be done in 20% of the time, but it is the remaining 20% of the work where 80% of the problems occur - hence that additional 80% of the time and effort is required to do a project well.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"
[ Parent ]

Why business apps sometimes suck (4.50 / 14) (#18)
by Caranguejeira on Thu Oct 26, 2000 at 11:07:24 AM EST

1) Software requirements are incomplete. The team is not prepared to start coding, but they do anyway because of the "deadline."

2) Requirements are not understood by the programmers. Programmers understand how to program computers, but not necessarily the symantics of an accounting system, etc. Lack of contextual design.

3) There are too many features, too few resources, and not enough time to do a good job. Someone forgot to let the development team control one of these aspects of the project.

4) The programmers are inexperienced with the feature they are implementing. This recently happened to me. Typically a hallmark of younger programmers, such as myself. They can program, but haven't really solved too many problems. This sounds like the main issue in the story that was posted.

5) The programmers are not interested in the system. They are being pushed too hard, get lazy, code sloppily.

6) Project managers have a tough job. Sometimes managers are inexperienced and make bad decisions. Some of them try to make all the calls themselves, without relying on the expertise of their staff. Projects that go seriously over budget and over schedule generally have management problems.

I know that some of you who are managers are going to be pissed at this. But it's true: managers are the ones who hire the bad programmers. They are the ones who put unqualified people on code they can't handle. They are the ones who, not knowing the capabilities of their own staff, still refuse to allow the project parameters to change. So what if the programmers suck? Whose problem is it? Management has the power to change these things. And if they can't, then they can at least guide the project so that it suffers less from incompetence. I'm glad I'm not a manager.

Open source projects don't suffer as much from incompetence because the programmers working on it have a vested interest in its success. Or at least they are willing to learn it. The developer who has the most interest in it is usually also the one who is managing it.

Carpenting (4.20 / 5) (#26)
by Swing on Thu Oct 26, 2000 at 12:26:53 PM EST

Quite true, though to be fair, most "carpenters," which we are, have been atrocious throughout history. In general, most people know that building something in the new way gets you money. Only a few people actually love the creations themselves, and a subset of them know how to work together with others.

I have a few suggestions that anyone can implement with little effort, even if the person (admittedly) is not a great manager.

1) Know where to point new people. Inexperienced people are usually a bit cautious, scared. That instability is partly because they don't know where to find things, or know where to read to learn about some technology. So, just know some books people like, and what's sitting in those cvs folders, if anyone happens to know.

2) Watch out for being too constaining. Some people need to be sort of forced to come in early. But you are hiring people you trust to build your architecture. You must trust them to some extent to know how they must complete something. Saying everyone must work 10 hours is pointless. Tell them to solve problems. Then most employees will find out that the solution involves coming in 10 hours a day or whatever. In other words, let them come to your conclusion, rather than forcing them by fiat.

3) Find out what makes people interested in making technology. Some programmers remain buggy & mediocre because they get easily frustrated, and just put in workarounds. It increases the time for development because everyone has to learn the workaround, deal with it. Maybe you can accept bugs, but you probably don't want increased dev time. So try to keep in mind it's best for people in general to actually be interested in programming. You can't do that much about it, except make sure the work environment has a couch or some red balls to sit on.

In other words, you want them to /think/. Thought is always faster than one's fingers.

[ Parent ]
Open source and incompetence (5.00 / 2) (#54)
by jorend on Fri Oct 27, 2000 at 06:29:05 PM EST

Open source projects don't suffer as much from incompetence because the programmers working on it have a vested interest in its success. Or at least they are willing to learn it. The developer who has the most interest in it is usually also the one who is managing it.

I think the key is that on an open source project, each programmer can adjust the scope of his work to match his skills and the amount of time available.

If you can adjust your task to fit your skills, you'll always be competent.

If someone else is defining your task, you may or not be competent. If a committee is defining the task, you are doomed.

In business software dev, many programmers feel uninvolved in the process of picking requirements and setting priorities. Non-programmer stakeholders feel that once a programmer has accepted a schedule, then if the schedule slips, the programmer must have screwed up. Many programmers, acutely feeling even the slightest pressure to perform, don't admit something is wrong or too hard until valuable time is wasted.

And this is before we even start to account for people making honest mistakes.

Concerning security: Open source programmers are self-selected for security-consciousness. They tend to be Unix hackers of one stripe or another, and the Unix world promotes a healthy concern for security.

-- jason



[ Parent ]
Labor Shortage and H1B (3.18 / 11) (#22)
by kostya on Thu Oct 26, 2000 at 11:45:56 AM EST

To raise a point that will probably get me fire-bombed: This is my main objection to raising the limit on H1Bs

The problem: not enough trained people to do software right. The solution proposed by many: open up H1s and bring more people over from other countries.

This just does NOT work. I have worked with many excellent programmers who are in the US on work visas. I have also worked with many awful programmers who are here on work visas. Their programmers are no better than ours. The fact is that with current H1s, we have probably stolen their best talent anyways (which has many implications, beyond the scope of this discussion). There are probably very few top notch programmers left who would want to come to the US. Raising the limit is not going to help our labor problems.

Our IT labor problems appear to be a problem of numbers. And that is a part of the problem. But the real problem is inadequate training. People are just NOT getting the basics. Even with a CS degree, many of these graduates still do not understand basic principles.

The problem is an immediate one that has no ready solution: we need to change our understanding of programming so that we can train the next generation right. I say this because many of the recent CS grads are just not as good as they *should* be. Is it there fault? I don't know. But I believe we need to seriously rethink CS and CS training. Because our workforce doesn't seem to be getting anymore skilled.



----
Veritas otium parit. --Terence
Poor education? (2.50 / 2) (#39)
by Icculus on Thu Oct 26, 2000 at 06:29:07 PM EST

The problem is an immediate one that has no ready solution: we need to change our understanding of programming so that we can train the next generation right. I say this because many of the recent CS grads are just not as good as they *should* be. Is it there fault? I don't know. But I believe we need to seriously rethink CS and CS training. Because our workforce doesn't seem to be getting anymore skilled.
In my experience, the poor skills in the programming workforce are not a result of a poor college education so much as the lack of one. Many of my coding cow-orkers are either business users turned coders or tech school products that learned VB but not software design. It's a rare pleasure when I actually get to work with a CS grad, or anyone with any formal CS training. When I do, they are almost always skilled, knowledgeable, and productive. whodathunkit

[ Parent ]
Shortages & Degrees & H1B, oh my! (5.00 / 2) (#51)
by scott@b on Fri Oct 27, 2000 at 11:18:24 AM EST

I, too, have had a fair amount of experiance in working with non-native engineers, both emigrants and on visas. My experiance was similar, some of them were good, some were pretty bad, and a lot were somewhere in between. I have noticed some cultural-based tendencies, but not strong enough to be able to make blanket statements on the abilities of "the typical" person from that culture. If there is any typical problem, it is that the second language may cause communication difficulties within the team; note that this works both ways - I'm not that great at any of the non-native-tongue languages that I attempt to use, generally the "fur'ners" speak Engish much better than my grasp of their language.

I've also worked with people without degrees, and with CS and EE degrees. Again, I've seen little consistency in how good of an engineer vs. having a degree. I worked at a company where 70% of the products had been designed by non-degreed engineers, and 80% of the patents came from that group (the company was successful, got bought by a big INC, (I left), got a standardised HR which reclassified said engineers downwards because of the lack of diploma, lost those engineers, and then went do the tubes). I've know degreed engineers that I wouldn't trust to design a flashlight or code hello world, a Masters in CS that couldn't follow the system design.

Younger programmers/engineers tend to be in too much of a hurry to implement, rather than design and document. Older folks tend to get stuck in the "we've always done it this way" trap.

I think that it comes down to differing people have differning attrivutes and skills. You run into
Coders - who are great at taking designs and making them into code, perhaps being able to squeeze a bit more performance or less RAM out of their code than you can.
Designers who do a great job slicing the system into clean chunks, with good partitioning of functionality and well crafted interfaces.
System architects who are great at seeing the big picture, and asking "so what if the user does this?"
Documenters who leave clear footprints, record decisions so others can check on that a week later when the memory of the meeting gets fuzzy, do comments that mean something, and generally make it possible to understand and recreate something a year later.

And people who combine several of these skills. However it's not too unusual to encounter a coder who would be best at doing FORTH; a screenful of code is about their limit of comprehension, whatever's not of the screen is forgotten. System designers that get bogged down when faced with detailed design, lost in code.

If you're lucky, you'll work on a project where there's a mix of these skills available, and the bosses will let thos people be used in ways that best fit their skills. On a smaller project this means that you'd best hope that the team members are good at wearing several hats.



[ Parent ]

Happens all the time (3.80 / 10) (#23)
by maketo on Thu Oct 26, 2000 at 11:53:12 AM EST

I have seen web sites costing > 50,000 $ sold to clients - sites people are aware of having _huge_ memory leaks that brought the server machine down. Response? Bigger memory in the server. hah! Security authentication for the site admins being done based (only) on an IP (clearly from behind a firewall all users might be the same to the servlet). Should a hypothetical person exist to propose a better authentication scheme, special tools for administration (maybe over SSL) etc. that person would be told that the site purchasers are not educated enough to notice the difference. Besides, in this situation, the purchaser agrees to take the risk...

See, it is not about lack of knowledge. I am sure that a team of qualified CS grads working in a company could sit down for a day/two and read on all this and implement it. It is more about attitude. Also about the greedy "managers" that jump into any business proposal they get, without properly evaluating their resources. This is because Software Engineering is still a moot point, more of an art than a science ;).

Now, if you are a person that likes to do a good, thorough job, you have two choices: quit the job or quit the job ;). Start your own company. Seriously, if you are good - you will make it. if not, I believe Chehov said that "life is a bowl of shit, you just need to eat it".
agents, bugs, nanites....see the connection?
ShortSighted Software (1.44 / 9) (#24)
by Swing on Thu Oct 26, 2000 at 12:07:10 PM EST

BROADVISION!!!

(Visit broadvision.com for a taste of their pain. Make sure you try backing out of their site.)

How very entertaining! (3.00 / 1) (#40)
by h0tr0d on Thu Oct 26, 2000 at 06:54:46 PM EST

Is this the internet equivalent of a revolving door that once entered has only one exit, into the building? I guess that would make it the e-revolving door.

-- It appears that my spleeing chucker isn't working again.
[ Parent ]

and broadvision gives error 500 on a HEAD request (3.00 / 1) (#47)
by mercenary on Fri Oct 27, 2000 at 12:14:19 AM EST

telnet www.broadvision.com 80
Trying 209.62.133.60...
Connected to www.broadvision.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 500 Server Error
Server: Netscape-Enterprise/3.6 SP2
Date: Fri, 27 Oct 2000 04:10:36 GMT
Content-length: 305
Content-type: text/html
Connection: close

[ Parent ]
Missing the real problem (4.08 / 12) (#25)
by krlynch on Thu Oct 26, 2000 at 12:14:25 PM EST

I've read all the comments posted to this article, and I agree with most of them.

However, I think that most of you are missing the real problem: security in most applications/systems sucks because people aren't willing to pay for it. If you WANT to buy a high quality, very secure application, you CAN find them...but they are few and far between because it costs FAR more to build them: the designers and coders need more training, the design takes longer, the coding takes longer, the debugging and QA take longer. As you are all aware, time is money.

While I am hardly claiming this as original thoughts (Bruce Schneier harps on this all the time), the situation will only start to improve when purchasers start to demand real security and are willing to pay for it; unless both parts of that equation are met, it won't happen. Managers or executives at a software company that spend vast sums of money to deliver features in products that aren't being demanded are not just being wasteful, they are violating their fiduciary responsibilities. It doesn't make them clueless or evil. It makes them smart.

To sum up, security in most applications/systems will continue to suck unless and until the customers demand improvement...and they haven't done so.

Convenience (3.50 / 4) (#36)
by jetpack on Thu Oct 26, 2000 at 05:27:57 PM EST

To sum up, security in most applications/systems will continue to suck unless and until the customers demand improvement...and they haven't done so.

I agree with you, but it's actually worse than that. Many of our clients don't even want security. They kick up such a major stink about the inconvenience of security in our products that we actually make our s/w configurable to eliminate security. They don't want to have to type passwords to access the database. They don't care that users can muck with each other's data.

Our security isn't perfect, but we are working on it. However, the better the security in our products gets, the more clients complain. Go figure.

Of course, some clients actually do care, which is why we are continually battling security issues. However, we always need to add the option to turn off security, otherwise many clients just don't want our software.

This is the subject of a rant I give at work frequently enough, and it does do some good, I think. But many clients just don't Get It, so we still have to support "dumb" installs of our product. Amazingly, I'm not aware of any complaints from "Don't Get It" clients related to people stomping on/reading each others data, but I'm waiting for the day it happens so I can say "I told you so" :)


--
/* The beatings will continue until morale improves */
[ Parent ]

Boy, do they pay for it. (3.50 / 4) (#45)
by BobSlaughter on Thu Oct 26, 2000 at 10:05:07 PM EST

However, I think that most of you are missing the real problem: security in most applications/systems sucks because people aren't willing to pay for it.
I'm not sure that's true. They are willing to pay for it, and often pay a lot for what is delivered. I think the problem is that shoddy software is being passed off at great expense. I've seen several packages that were highly expensive that had major flaws in them [Note 1], but they cost about the same as other vendors products that were much more solidly built. Too many software sales don't involve technical reviews, but are arrangements between sales people (great at social engineering, and all too often have no technical knowledge of the product they are pushing) and clueless managers, who base their decisions solely on sales literature and presentations. Good sales people and managers who know the needs of the industry (or who know they don't, but are willing to rely on those who work for them who do) are true treasures, but are all so rare. Note 1: Vendor shipping a release product that won't run on their own UNIX platform. Product relies on the perl interpreter being in /usr/local/bin, but this vendor places perl 5 in /opt/perl5/bin, to avoid clobbering perl 4, in /usr/bin. The coders of this Windows/Java app never actually tested their install of the UNIX integration script on their own vendor's UNIX sytem. When we worked with them on fixing this, they said they'd have it out in their next Service Pack, in the next few months. No patch until then. This for six-digit software!

[ Parent ]
Security in software? (4.16 / 6) (#31)
by jeremya on Thu Oct 26, 2000 at 02:51:51 PM EST

Hello All,

I would like to take a few moments of my day to share some of my experiences in application development.

First I have worked in a environment in which SQL 7.0 was used. Users had access to an entire database of sensitive insurance related data.

The passwords were stored as plain text in a SQL server in which the super user pass was left as the default. The system was publicly accessible over the internet. The servers ran IIS and most likely contained various IIS related exploitable "features"

This is all to the bad. However to the good (not that it truly mattered) All data validation was performed server side. Javascript was used but only as a matter of convenience to the user so that their forms would not be submitted without data being validated so they did not lose all of their changes. After this the server also validated all data and made sure nothing like a buffer overrun was possible etc.

The system had otherwise decent "security"

I now work for a different company and we are very security minded. We hash all of our passwords and any sensitive data. I surf Bugtraq, and test things to the extent of my knowledge. I Implment scripts designed to perform DoS and test all known exploits for our OS/web server platform.

The point of all of this is simple. Security should be thought out in the entire design of your product. If security is an afterthought, it just wont happen even if you sit a group of CS students down to implement an algorithm. It takes carefully planning by management, and enough talent to implement a carefully planned and programmed security scheme. If this does not happen then security can't happen.

The truly sad thing is even with a two man company we are able to make our applications incredibly secure just with a little forethought and planning and some basic knowledge of what security is and what it takes to make it happen.

It seems to me now a days security is treated as a feature and not something truly important... I truly wish this was not true. Look around and you will see how seriously most people take security.

I have tested on perhaps 20 random sites using a certain HTML preprocessor and over half of these sites had exploits fixable within 45 minutes. Bugs that have existed for over a year... Oh and its not such a great idea to tell a company they have a bug, you are greeted with open hostility and threats. (How dare you break a "feature")

So I must agree the state of security is very very poor on the whole. While the knowledge and know how of almost all security has already been done and thought out EG:by Bruces book read for maybe a week and you can be made aware of a great deal of what security is really about.

So.. I think it is rather important situation where companies obviously do not care and security is only an afterthought to the consumer and the consumers privacy. Which more or less says many things about most companies. Security is an afterthought, greed and making money are all they truly care about.

Any company should care about making money its one of the most important things to a company, but never at the cost of something so great as sacrificing your clients well being.

Unfortunately we are one company against many offering something most people dont even know or care about sothe true question is how can we make a difference and inform people of these issues, not merely note that they exist.

Jeremy

From the trenches (3.80 / 5) (#33)
by nicksand on Thu Oct 26, 2000 at 03:18:13 PM EST

For the last two years, I worked in a company, programming applications similar to the type described in the story. Basically, we made an application geared solely to a specific indusry which we charge a pretty large amount for (compared to consumer software costs). When you are talking about the costs of this kind of software, you have to keep in mind the market that it's being sold to.

The story mentions that a ten thousand dollar program should have way more energy and expertise put into it . . . but do a little math:

  • $50 * 100,000 copies = $5,000,000
  • $50,000 * 60 copies = $3,000,000
Because of the much smaller target market, the software naturally needs to be more expensive.

However, please don't get the idea that I'm excusing shoddy security practices such as the ones described in the story. Personally, I'm proud that I introduced the use of SHA hashes for user passwords into the ColdFusion web-interface that I was responsible for. Both my boss and my coworker fully understand the reasoning behind this and support the idea (and will undoubtedly use it again in future product releases). I also security-audited all the code that I wrote, and designed the application infrastructure to automatically detect what I anticipated would be common intrusion techniques (eg: force feeding variables via the url line).

Ultimately, there are two people who can help make such software secure. The first is the programmer, because he is the one actually implementing the system. The second is the customer, because he has the power of the purse strings. Customer power is especially strong for high-cost programs targeted to niche markets . . . a well-placed complaint with the right person should go far

- N

PS: please note that I (a) no longer work in this company, I am now working on my formal education at a university, and (b) that the demonstration numbers I used do not reflect the company's prices/sales.

Without trying to sound elitist..... (3.00 / 3) (#35)
by 11oh8 on Thu Oct 26, 2000 at 05:01:59 PM EST

I don't want to sound elitist but i have to say this... I am at a good 4 year Comp Sci program about to finish!!! We don't learn much about "real world" programming but we do learn quite a bit of algorithms and generally get a good idea of how to write good programs. I don't think it's the best way to teach (very few students know about any real world programming and if they do it's because they learned it on their own) but it at least gives students a pretty good foundation. Now, there are many (maybe even more than CS grads) programmers who learned programmig in six months using a VB book.. And many of these programmers (who don't know what a data structure is let alone security - but it's not really their fault) end up writing pretty critical software....

case in point: myself.
During my freshman year, I worked at a small local software copany.. I had no CS knowledge back then. I had played with MS Access and VB for fun and was the "MAIN" developer for their application. This was an application used by several businesses. Everybody in the company had mainly a business background (accounting to be specific) and I was the one giving them design suggestions.. I did my best and gave good suggestions based on what i knew but there was SOOOOOO much i didn't know then... The fact that I had so much power seemed cool then but seems a little scary now... and i think that this is a pretty common thing in many business developmnent places where many apps are VB or MS Access type stuff....

Since the business guys in a company don't have much technical knowledge, they have no skills to discern good suggestions/products/companies from bad ones... Colorful dialogs and fancy graphics seems to do more than a good algorithm because they are way more visible...

$.03,
11oh8


algorithms (3.00 / 1) (#37)
by Delirium on Thu Oct 26, 2000 at 06:03:54 PM EST

That's exactly the reason that, while many people claim that a 4-year-university is useless for people in the tech field, I still see it as valuable. You might not learn the specific technical things you need for the job, but you can learn those on your own anyway. You do learn some things about complex mathematics and algorithms that you might not have on your own. When you then have to write a program, you might not be using the most efficient method.

[ Parent ]
I agree... (1.00 / 3) (#38)
by 11oh8 on Thu Oct 26, 2000 at 06:17:39 PM EST

While my computer science theory classes and algorithms classes were one of the most boring ones, I use the knowledge from them quite a bit while programming.. time/space complexity is always in the back of my mind when i'm programming and while i might not formally analyze my code to calculate it's time complexity, i do consider it when coding... These kinds of things are very lacking in many comanies... and the fault goes not just to the programmers but also to the management who doesn't even know of the existence of such things... 11oh8

[ Parent ]
I agree... (2.50 / 2) (#41)
by 11oh8 on Thu Oct 26, 2000 at 06:57:50 PM EST

While my computer science theory classes and algorithms classes were one of the most boring ones, I use the knowledge from them quite a bit while programming.. time/space complexity is always in the back of my mind when i'm programming and while i might not formally analyze my code to calculate it's time complexity, i do consider it when coding...

These kinds of things are very lacking in many comanies... and the fault goes not just to the programmers but also to the management who doesn't even know of the existence of such things...

11oh8

[ Parent ]
I agree (3.00 / 2) (#55)
by duffbeer on Sat Oct 28, 2000 at 12:27:11 AM EST

I am a newly-minted CS grad, and I thought that my education was pretty useless when I was in school.

I'm a dba and don't do too much programming beyond the occasional perl or shell script, but it seems like a have a better intuitive understanding about why things do what they do over my colleauges without degrees.

looking back, i'm glad i stuck with it.


[ Parent ]
Most people don't try to sound elitist (3.00 / 1) (#52)
by cypherpunks on Fri Oct 27, 2000 at 01:36:46 PM EST

If you want to learn a programming language, read a book. And setup a BSD box and start hacking away (well, okay, any platform where you can get the dev tools for little or no financial investment).

If you want to learn how to program and how to design software, go to college. Well, college in the US, other countries actually have respectable technical schools. You can either invest ten years of your life learning the hard way, or you can spend 3 to 5 years learning things in a much more conducive environment.

And if you ever find a CS/CE program that emphasizes things like "Don't use an unbounded %s in format strings", please tell me.

[ Parent ]

The thing about special purpose stuff (4.00 / 6) (#44)
by jabber on Thu Oct 26, 2000 at 09:31:25 PM EST

I've worked as both a recipient of custom/special-purpose software and as it's developer.

My experience has been that you are completely right. Special purpose apps have HUGE gaping holes where the security ought to be. They're also missing many other features, such as Usability, Customizable look-and-feel, Conformity to OS UI standards, stability/robustness/fault tolerance and decent performance. But...

Often they are one of very few applications that do some specific thing well enough. They are intended to be scalpels, not utility knives; and as such, they need skilled hands in a clinical environment to do their job well; use them wrong and they break. They are, after all, custom software, not general purpose software. They are designed to the users "exacting" specifications, and if those are lax then who is to blame? They are also often designed for a very strictly controlled environment. Hardware, software and access-wise.

We presume that all our co-workers are diligent, responsible, ethical professionals. Maybe it's too much to ask for in the extreme cases, but in most it is true. Few employees seek to destroy the work that they do. So, the security concern lies on the far side of the firewall, behind which our custom application will run.

We presume that the people who will use the software are intelligent enough to RTFM, and not subject their special purpose software to bizzare situations. A general purpose application, such as a retail word-processor for Windows98, has to run on a wide variety of platforms, along-side a zoo of other software. Retail applications are designed to be treated with disrespect, by their peer applications and by their users. Retail software has to take the ID-10-T error very seriously, while custom software assumes a knowledgable user in most cases. Custom software can, for example, assume (via spec) a certain color depth and screen resolution. Kibo help you if you mess with a programs assumptions. :)

Am I saying that this is good? No, absolutely not. But, if the custom code is developed by a relatively small group of coders (say a dozen or so) on a 'lowest-bidder' budget, with incomplete and variable specs and reqs... With a deadline that is unrealistic from the get-go... What else can you expect?

Shops like Micro$oft can afford to plan to devote a 100 people to a project, and to bring in fresh horses every once in a while. They also can get away with delaying delivery indefinitelly - after all, the retail customers will still be there next month, next quarter or even next year.

Custom projects can get killed on day 1 past-deadline, at 95% completion, with no payment. So such code tends to be held together with twine and bubble-gum. It needs to get THERE, and then, if there is time (AND MONEY) it will get upgraded. Custom coders are not proud of the sacrifices they have to make; they want to deliver the best product they possibly can. And, speaking from experience as both a consumer and provider of such code... Often times the kruft you get was the best possible compromise given the available resources.

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

XOR security can be exactly what's necessary (2.66 / 3) (#48)
by mercenary on Fri Oct 27, 2000 at 12:26:52 AM EST

I have seen some situations recently where simple, breakable XOR security is exactly what's needed.

Usually these are programs which are shipped by the vendor and include data which they have licensed for the application, but not for redistribution to end-users. Think of picture encyclopedias.

I know, and they know, that because I have the executable I can start a debugger, step through the code, and find out how the data is scrambled. (I won't call it encryption.)

Why is this sufficient? Because all they need to do is make a reasonable effort to obscure the data. If they find out that I'm using the data in pure form, they'll know I reverse-engineered their code, which is often a violation of the license. Even better, I'm using in ways not allowed by the license.

It's not worth it to come up with some incredibly complex encryption scheme to protect the data. But the company is bound by license to not ship the data in plaintext.

I'm curious to see if anyone has ever been sued for unscrambling data and using it for purposes other than for which it was intended.


I can think of one... (3.00 / 1) (#56)
by klash on Sun Oct 29, 2000 at 12:51:58 AM EST

I'm curious to see if anyone has ever been sued for unscrambling data and using it for purposes other than for which it was intended.

Is this a rhetorical question in the form of poetic ignorance? :-)

If not, well, DeCSS comes to mind. All hail the DMCA which makes it all possible.



[ Parent ]
:CueCat (3.00 / 1) (#57)
by KindBud on Sun Oct 29, 2000 at 05:09:00 AM EST

'nuff said.

--
just roll a fatty

[ Parent ]
Reverse-engineering (none / 0) (#60)
by Peeteriz on Mon Nov 06, 2000 at 06:22:22 AM EST

In many countries, reverse engineering and other things, even if specially prohibited by the license, is allowed.
Unscrambling data is sometimes neccessary, if you want to bulk-copy data to another format, but the app you have been sold does not support it. (e.g. a legislation database that stores its data encrypted, and supports viewing of a single law, but does not have a function to export to a text form to allow grepping of it)

[ Parent ]
A good example (3.00 / 1) (#61)
by xhypertensionx on Mon Nov 06, 2000 at 01:51:21 PM EST

It would seem obvious that programs that cost businesses tens or hundreds of thousands of dollars or more would have way more time, energy, and expertise put into them than $50 programs you find at CompUSA, right?

A good example of a business application that was horribly overpriced is Apple's WebObjects - webserver programs (i think) and other stuff that was written entirely in Java.

Starting Price: $50,000. No shit.

After that, it went down to something more "reasonable" -- $799. Can you imagine how you would have felt if you bought it at the original price, and had to explain to your boss that you basically wasted $49,200? On a single piece of software too...

Security in business apps | 61 comments (61 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!