in reply to Re: 'Restricted' data, an additional security mechanism for Perl.
in thread 'Restricted' data, an additional security mechanism for Perl.

I agree with you 100% on your post about it not protecting the user. I'm just discussing what the point of it is there for. :)

It's not security against people and getting secrets from the system. Lemme give you an example. Say someone who is writing an encryption module, doesn't want you messing with the initialization vector because it holds no value to other developers, then making it private is up to that developer. The users aren't always people on the other end of a program, but also people who develop using your API. Those people who write the API are the ones who define the architecture to be "upheld".

I'm just pointing out that while yeah, it doesn't protect end users in the long run from getting data out of the system. Just make the process core dump, right? That protection is against people extending the system (or playing with it) in awkward ways that they shouldn't depend on. It might change, or may break something. That's what upholding the architecture is about. It means developers don't do stupid things and make it really hard for them to do just that and keeping the ideas behind the system right

It's the bars around dangerous machinery. People aren't trusted to not hurting themselves. For perl, the bars are a simple line in the sand saying, don't cross this line. For some languages, it's a steel wall.


Play that funky music white boy..
  • Comment on Re: Re: 'Restricted' data, an additional security mechanism for Perl.

Replies are listed 'Best First'.
Re: Re: Re: 'Restricted' data, an additional security mechanism for Perl.
by hardburn (Abbot) on Feb 09, 2004 at 22:13 UTC

    With my orginal post, I was thinking of the situation where you read a password from the user, check it in a database, and then get rid of it. Having it automatically self-destruct could be handy. Abigail pointed out that this is probably useful in far fewer situations than I thought it might be.

    Also, it could force you to rely on the implementation of certain functions. For instance, your password-checker sub's first implementation might only need to fetch the password once, but a later implementation fetches it twice. Now you have to increment your self-destruct paramameter in a place that might be very distant from the password checker sub.

    In any case, it was just a brainstorm. A thought placed Out There without any initial prejudice.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      I'm dealing with the same exact situation you are right now. I store it in the app after it's been verified in one-way encrypted form. Worse for worse, I am weak against replay attacks, but at the same time, his password is a little safer, since only the encrypted form of the key is known, not the original. At least then, if the system is compromised, the black-hat won't try the password in other places, (bank, school, personal stuff.. etc)

      Play that funky music white boy..
[reply]

In Section Meditations