|
Until something is hacked, you don't have to worry about it
Hogan
|
|
|
|
|
I think that many small company think like that...
And also think that if a problem occurs, it could be fixed in no time and without much consequence while in reality the code was mostly not written with security in mind often from people that does not know how a system can be hacked... Thus if such problem occurs, the might not have any idea of what to do.
Philippe Mori
|
|
|
|
|
For example, if you develop a web site for a client, then that client has to specify that he wants a secure web site.
Obviously, if the site allows to make financial transactions or keep informations that are really confidential (like credit card numbers), those who are responsible for the development should take appropriate actions.
For anything in between, it should be specified in the contract if the user want a given level of security and obviously the cost of building the system should be adjusted to implement and validate desired security level.
Obviously, a programmer should follows good programming practices like using parametrized SQL queries, storing hash for passwords and using secure RTL functions to reduce the possibility of systems being compromise by taking advantage of that.
Philippe Mori
|
|
|
|
|
I have a friend who studied accounting, he ordered an online shop to a company.
When I asked him about if the web was SQL-Injection secured, he was like
Let me translate your comments to another discipline:
if you are ill and need medical attention, you need to tell the doctor, which organ of your body must be healed or which medicament do you agree to take. And that, without knowing which kind of illness you have.
Obviously if you have an accident and you are bleeding, the doctor should close your cuts and try to stop your bleeding.
For everything in between, you need to specify it in the contract if you want to get 100% healed or if you want them to cement your broken leg.
Obviously a doctor that treats patients should follow good practices, like washing his hands, using sterile tools to recude the possibility of an infection.
Would you think the same if you were that patient?
I see the "money" factor and what is on the contract and all this argumental line, but at least is your responsability to explain what are the options, the risks, the costs and possible alternatives. Then, and I repeat then what you say can be accepted. You can't push the responability about something to someone who has no idea and is paying you for your work.
If you explain everything to the customer, and he still wants do things in a particular way... then it starts being his fault. Before that point... it is entirely responsability of the developer.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 24-Oct-16 11:32am.
|
|
|
|
|
Well, from what I have seen is that is the customer does not specifically ask for things like HTTPS, not much would be done for security...
In fact, I have seen system security be somewhat decreased by making the "lost password procedure" more user friendly.
I have also heard a lot of answers of the type "the user does not care or does not need to know or that peoples are honest..."
Philippe Mori
|
|
|
|
|
... because that's who may be held accountable for security breaches or their consequences. Pointing at anyone else will not work if something like this ends in a courtroom.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
When it comes to security, the developers do what the security officer says, not what the developer says.
If you have a good security officer (and team if you are so lucky), then you should have a robust system, security wise.
It has been my experience that most developers don't really know anything about security, even if they think they do, they really don't. 
modified 24-Oct-16 8:17am.
|
|
|
|
|
"There can be lots of fingerprints on that knife"
Sounds like a good blamestorming session. In my experience it's best to pick someone who's out sick or on holidays, that way they aren't there to defend themselves.
|
|
|
|
|
The best are those who resigned, as they won't be back with a vengeance.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
The bigger the c**k-up, the higher the blame should travel:
The developer should get it in the neck for being incompetent.
The testing team should be carpeted for not spotting the developer's ineptitude.
The PM should be hung out to dry for not keeping an eye on the ball.
The HR team should be slammed for having hired the aforementioned failures.
The CEO should fall on his sword because he's clearly running a ship of fools.
The buck has to stop somewhere.
|
|
|
|
|
|
In my opinion it is most of all the responsabillity of the programmer.
Sure there are the basic response as, the user can leave the password on default. Yeah but the developer can also create a piece of software that makes sure that the default password is different for each machine and the password needs to be changed on the setup.
|
|
|
|
|
In our software we tried it and failed. Users (actually power users) set password that they forgot, got locked out of the system with everything encrypted and opened legal actions because we did not provide any recovery option - hard to do if you encrypt with a user defined password. And they refused to pay all the machines they bought from us (in the same shipment) and sent them back to us. Basically some hundred thousand euros burnt away for doing the right thing.
So we now have all kinds of backdoors in order to save w*kers (wORKers of course) from themselves and our axes from the CEO.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
den2k88 wrote: If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver I still do that a lot. My old CDP1802 processor does not have an instruction named JMP. But of course I can't live without any BX (branch on condition X) or LBX (long branch on condition x).
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Obviously, the way to recover would not be to send them the lost password but to send then an email to recover lost password...
And I would say that you should not compromise for a dump client but instead explain them why doing otherwise would make the system less secure... And if the client has not specified explicitly in the contract that he want to be able to recover user passwords, in which case you should have discuss the issue with them, then you should not accept that they send back the system...
Obviously, if you wait until the end of the project to get paid, then the have the advantage over you... So in my opinion most of the development cost should be paid as it goes and be not refundable.
Philippe Mori
|
|
|
|
|
These are machines which store their own data offline and they usually work with no access to the internet (industrial machinery) so if you lose the encrypted data and recipes you lose every trrack of what's passed through the machine.
So there is no reset password if data are encrypted - and we accept everythign for everyone because we like to bend to every id-10t for a scrap of bread. That's our CEO policy at least.
Machines are sold with the software, so it's not a project but a sale of an object + eventual customizations, which usually are paid on delivery.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Instead of sending the old password, you can send a newly generated one... the main problem being that one would reset the password of someone else. Thus, you might keep both password until new one is confirmed...
Or you might have an admin account that allows to change any password...
Philippe Mori
|
|
|
|
|
If a developer does not have support from above and they do not care about security, then that developer would probably never have the time necessary to invest in security because they would ask him many other features...
Philippe Mori
|
|
|
|
|
In my own opinion, I believe everyone is a culprit, from the machine, to software application, to system admin, to end user. A flaw can be left anywhere and that can cause a security problem.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Haven't seen her mentioned in a while.
I guess she's in the "None of the above" category
Also, does anyone know how secure the CListCtrl is?
|
|
|
|
|
Salma Hayek certainly isn't a "None".
But at the moment, the only survey I want to see her in includes the words "Best" and "Motorboat".
|
|
|
|
|
Sander Rossel wrote: does anyone know how secure the CListCtrl is?
Depends on the quantity of Bacon involved.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
* The developer who wrote the software: he's responsible of the absence of security bugs and backdoors, and of writing the documentation. Also he has to implement correct security practices (avoid the possibility of using clear text outside of debug environment, avoid then usage of weakly encryption methods...).
* The person who installs the software: he's resposible of reading the documentation and applying the proper policies. If developers use the best and safest technologies and the installer trumps them with shared accounts and unshielded servers there's nothing to be done.
* The user: please avoid post its with passwords, installation of wareZ on the clien machines, looking at "The newest new funny videos with cats!!" on the workstation.
The person who recommended the use of the system isn't responsible of the bad installation and usage of such. The person who decided on the default settings of the system may have a little responsibility but it's not his fault if the installer is incompetent. He may have had its reasons to put up those defaults.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|