"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.
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.
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.
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.
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...
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...
* 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.