in reply to Security: balancing two conflicting password policies
Store in your code two strings of the same length, some length longer than the password. At runtime, xor the strings together using perl's a-string-is-a-bitvector feature. The strings will have been chosen so that the result is the desired password.
Okay, that's one level. Now, what I would suggest is that you in addition write a script that prompts for a password, and mangles some other script to include the password as two variables as above. (Probably through something as simple as s/__RANDOM_STRING__/$randstr/; s/__PASS_XOR_RAND__/$pass^$randstr/e;) Then, this automatically runs pp over the mangled version, and deletes the mangled script. Call this second script your "build script".
This has the advantage that the password is in plaintext only in the memory image of the running program, and is not even deriveable from the source as it sits in your source control. The password is deriveable from the compiled executeable, but that's a necessity.
Of course, you don't need to use xor "encryption"; this method can easily be adapted to use Blowfish or AES or some other cryptographic standard that sounds impressive. (But really, what do you gain?)
Anyone ever think that some policy like this is behind the rot13-encrypted data in the windows registry?
-- @/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/
|
|---|