http://www.perlmonks.org?node_id=890412


in reply to Re^5: Authentication with /etc/shadow
in thread Authentication with /etc/shadow

Yes, checksum is a good idea, I'd already decided on hardware checks.

Also, checking code is kept in the main loop - no function calls - for the reason you suggest and is encountered prior to any sensitive functionality. (also duplicated within the most sensitive function block in a .pm file) If any checks fail the program goes into a blind loop and never encounters the sensitive instructions

I suppose I am, in the immediate instance, trying to rely on and beef up the limited security value of perlapp executables in order to buy myself some time to develop a better solution. My hope is that a perlapp could not be easily decrypted cold and that it would probably be run to be cracked. When it runs I may be able to get lucky.

I know it's a less than perfect situation but it's all I've got now, this minute. I can only do the best I can with the tools I've got in the situation I find myself.

Perl is an unbeatable problem solving and prototyping system. It has solved problems here that I doubt could have been as well done with other languages. The client is well pleased, so pleased they are insisting on going live NOW, with a Perl only setup. They have "Confidence in my ability to safeguard their interests" .... They are non-technical and have more confidence than I do...

Replies are listed 'Best First'.
Re^7: Authentication with /etc/shadow
by ELISHEVA (Prior) on Feb 27, 2011 at 13:50 UTC

    Ah.. the old "the prototype works so well, why do we need the real system?" That surely isn't an easy situation. No one wants to spend more money than they have to.

    Would they be open to a conversation about the different goals of prototyping and why prototyping often looks like a complete system when it isn't? One analogy that you might want to play around with: a prototype is like the costumes and scenery in a period drama. The costumes often look authentic and they successfully support the story. You can dance and sing and act in them.

    However, those costumes are rarely wearable on the street. They would never make it through the washing machine. Seams are basted or pinned rather than stitched. Materials that look like silk are used instead of real silk. Cloth with the durability of gauze is used instead of sturdy broadcloth. Buttons and zippers are fake - up close the clothes use cheap snaps and clasps that easily tear off.

    A prototype is like the period costumes. They are good enough to give a realistic feel for what the system does and to ferret out any logical inconsistencies in the design specs. However, they aren't designed for operational strength because that would take time and attention from the more important job of making sure developer and client truly understand each other. If you want to wear stage costumes on the street you have to turn those pinned seams into stitches. In the same way if you want long term durability and security, you sometimes have to rewrite parts of the prototype in a more robust medium.

    Good luck!

      Yes, exactly. But they see big fat dollar signs. Every day wasted loses them more than I earn in a year and if a competitor beats them to it they'll be jumping off ledges.

      So do you think I have a chance of beefing up the perlapps a bit?

      I personally have never really considered how to crack a perlapp and maybe that's the question I should have asked.

      It seems to me that the crux is likely to be - Does the perlapp need to be run to be cracked (I'm assuming yes) and if it does will it be run and controlled or run and observed. If the instructions are encountered sequentially and observed then I have a chance of making a right pain in the *** of myself for any attacker. If it is not processed sequentially or is stepped through like a debugger - under human control - I am probably powerless to hinder them more than once, if that much.

      What I really need is another month but it isn't going to happen.