Secure password
-
I just got out of a phone meeting about a new project that I am working on. The app that I will be writing is going to be the front end to a machine that prints important (and potentially valuable) information on blank cards. Normally the app will get setup information from a DB, but part of the requirements involves a password protected screen that will enable the operators to manually configure the setup and run arbitrary print jobs. Given the value of the product and my belief that the customer values security I raised a question about how this password should be managed by the app. I was told that it should simply be placed as plain text in an INI file and to " .. put it on like the 3rd or 4th line, but don't call it a password." Oh .. and there is to be no logging of who actually uses this manual mode either!
That's not the only WTF. The job was quoted as a fixed price with ill-defined requirements, and the questions I raised were typically answered with - "there's no budget for that". Its turning into a great example of an anti-customer centric development process. Fortunately I get paid by the hour.
-
@OzPeter said:
I hate to say it, because it's bound to start another flamewar, but security through obscurity is fine for many, many uses. How many people keep a spare key somewhere in their front garden? Things secured by keeping them secret aren't very secure, but they are usually secure enough for their purpose.I just got out of a phone meeting about a new project that I am working on. The app that I will be writing is going to be the front end to a machine that prints important (and potentially valuable) information on blank cards. Normally the app will get setup information from a DB, but part of the requirements involves a password protected screen that will enable the operators to manually configure the setup and run arbitrary print jobs. Given the value of the product and my belief that the customer values security I raised a question about how this password should be managed by the app. I was told that it should simply be placed as plain text in an INI file and to " .. put it on like the 3rd or 4th line, but don't call it a password." Oh .. and there is to be no logging of who actually uses this manual mode either!
That's not the only WTF. The job was quoted as a fixed price with ill-defined requirements, and the questions I raised were typically answered with - "there's no budget for that". Its turning into a great example of an anti-customer centric development process. Fortunately I get paid by the hour.
Not logging usage is more worrying that not having a very secure password, but both would seem to indicate that they trust their operators. Or maybe they're just insanely dumb, this really is a WTF, and I don't know the first thing about what is going on in your place of work :)
-
@OzPeter said:
Given the value of the product and my belief that the customer values security I raised a question about how this password should be managed by the app.
Would something like an agent be acceptable? (See: ssh-agent and gpg-agent)
-
@davedavenotdavemaybedave said:
I hate to say it, because it's bound to start another flamewar, but security through obscurity is fine for many, many uses. How many people keep a spare key somewhere in their front garden? Things secured by keeping them secret aren't very secure, but they are usually secure enough for their purpose.
Not logging usage is more worrying that not having a very secure password, but both would seem to indicate that they trust their operators. Or maybe they're just insanely dumb, this really is a WTF, and I don't know the first thing about what is going on in your place of work :)
In general for most systems you don't need much in the way of security, and I'm all fine for some obscurity (I have been toying with encrypted App.config files but even that only really stops you from taking the data off the machine - if you are on the machine then its really just another form of obscurity).
But as a similar example (and not connected with what I am doing, but possibly of a similar level of importance), how would you treat the passwords for manually setting up the printers that spit out drivers licenses at the local DMV? I'm sure the customer is not dumb, their website is full of lots of language that says that treat security and auditing very seriously, and I'm sure they only trust their operators as far as they can throw them. What I am suggesting is that what we are proposing is insanely dumb - I was shut down for even thinking about asking the customer what their expectations on security would be. Actually "proposing" is not the correct word "doing" is, as there is nothing in the budget for anything else
-
@Lingerance said:
Would something like an agent be acceptable? (See: ssh-agent and gpg-agent)
Bzzzt .. try again .. no money for that in the budget! (thats what I have to deal with)
-
@OzPeter said:
." Oh .. and there is to be no logging of who actually uses this manual mode
Given that said procedure has apparently some monetary value, this one's rather worrying. Could you not hide a log in plain sight as they request for the password? ROT47 if desired.
either!
-
@PJH said:
Given that said procedure has apparently some monetary value, this one's rather worrying. Could you not hide a log in plain sight as they request for the password? ROT47 if desired.
I can do what ever I want to do, but I will have a fixed budget and going over that budget is frowned upon, and I will be doing requested features first and then seeing what I can pad my invoices with. However I am doubtful that there will be any money left over after I do the requirements.
-
@OzPeter said:
@PJH said:
One would assume that, during development (charged, of course) that some debugging of data would be taking place, and that the removal of debug would either constitute development cost (it's needed there to do the job) or extra work (since it's, um, not now required due to specs).Given that said procedure has apparently some monetary value, this one's rather worrying. Could you not hide a log in plain sight as they request for the password? ROT47 if desired.
I can do what ever I want to do, but I will have a fixed budget and going over that budget is frowned upon, and I will be doing requested features first and then seeing what I can pad my invoices with. However I am doubtful that there will be any money left over after I do the requirements.
I do see the conflict, I'm not so sure about why 'bending' the perceived rules of engagement in this particular role of employment are verboten. More-so if (I perceive you're a contractor) you're moving sometime soon.
-
@OzPeter said:
But as a similar example (and not connected with what I am doing, but possibly of a similar level of importance), how would you treat the passwords for manually setting up the printers that spit out drivers licenses at the local DMV? I'm sure the customer is not dumb, their website is full of lots of language that says that treat security and auditing very seriously, and I'm sure they only trust their operators as far as they can throw them.
In that example, I'd be tempted to say that I wouldn't secure the printers at all - I'd secure the printing facility against unauthorised removal of licenses. It doesn't matter what someone prints if they can't get it out of the building, and you need that kind of security anyway to secure the legitimately produced licenses. I'd even go further, and say that securing the printer technologically may actually detract from security: if everyone thinks the printer will only print authorised licenses, then no-one will take any notice as Bill Felon prints a stack, but if anyone could print anything, they'll wonder what he's doing.@OzPeter said:
What I am suggesting is that what we are proposing is insanely dumb - I was shut down for even thinking about asking the customer what their expectations on security would be. Actually "proposing" is not the correct word "doing" is, as there is nothing in the budget for anything else
Well, that's different :)
-
@OzPeter said:
I was told that it should simply be placed as plain text in an INI file and to " .. put it on like the 3rd or 4th line, but don't call it a password."
Nothing wrong with that, if you keep the INI file under strong encryption.
-
I normally think of it like this: Gather the system requirements, however insane they seem to be. Develop the app to match those specifications. If they want passwords stored in ascii text files, fine. The customer is paying for bespoke development, not a consultant. Deliver the resulting application. When they decide there specifications were crap, they'll submit a specification change request and you can charge for the modifications and new version. You are giving them exactly what they asked for. If it's a fixed price contract you are doing more work for nothing.
-
@Mole said:
I normally think of it like this: Gather the system requirements, however insane they seem to be. Develop the app to match those specifications.
Quite a reasonable approach .. but this is what happens:- Sales person (and project manager) sold concept to customer on a dream and at a low fixed price.
- Said sales person does not gather sufficient requirements to properly specify the job (or does not care to collect requirements).
- When I question the holes in the requirements I get told by the sales person that the software will work this (arbitrary) way
- The customer does not know of these decisions and will be told how the bespoke system that they want will operate.
- I quote a price for what I believe it will take to build the system based on the stated requirements
- Sales guy attempts to beat me down to bare minimum costs for my quote. (Note that the more my quote is then the less profit for them)
- I resist beating as much as I can and produce code to meet all requirements as given to me
- Customer sees final product (waterfall model here and not by my choice) and says that supplied features don't meet their needs
- I implement customer desired features and bill for work. My time now comes out of profit
- Company owner is pissed because the projects I work on never seem to be making the minimum desired amount of profit
- Sales guy is totally oblivious to the issues that he is causing
-
We don't sell a lot of single solutions, we can build something and sell 10,000 of them or so. Of course that means trouble with small portion of our 'sales' people. Ie, 'sales' person gets verbal contract from customer that he'll buy 10,000. We cost on them buying 10,000. Customer decides requirements have changed and buys 100 and so we make a loss on the product.
The WTF is that these 'sales' people are normally high up in the company (eg. directors approached by customers) that think they know how to sell. The worse thing is that they only see "each one of them cost $100 to build, we sold at $200 each. 100% profit!". They don't see "6 months of development time = $100,000" so for an order of 100, they cost $1,100 each to produce, so our loss is $90,000.
I try to ignore the above and just keep bringing home a fixed pay cheque, as I almost never work overtime except in a few special cases of above 1 - 2 hours per month.
-
@Mole said:
My problem is that my Sales Idiot seems to think he is selling a generic product that can be magically transformed for free into what ever a single customer wants and then bitches when I quote how much it will cost to deliver the specific requirements. And all the time I am battling to keep that specific code out of the generic code baseWe don't sell a lot of single solutions, we can build something and sell 10,000 of them or so.
Actually now that I re-read your post it sounds like we are in basically the same position
