0
$\begingroup$

I'm inheriting a project that stores a used password in a config file, which is generated by the user giving their password in plain text, and the project giving back a key generated through .NET's Rfc2898DeriveBytes with a given salt on the aes encrypted cipher text (which the user then has to put in the config themselves). The password is decrypted and used when the project starts up for that user.

Since the key and salt are statically compiled into the project as strings, it seem kinda pointless to me, like basically its the same as storing a jibberish password in plain text, with added overhead, right?

Am I missing something here?

EDIT

After asking around about the code, the point is that we're giving this application to a different team to run under a network domain account, so we wanted to prevent them from having the password for the account the program is supposed to run under.

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Your protocol description is not clear to me. Are there two passwords, one in the code and one used as input by the user? On which one is PBKDF2 (RFC-2898) used? A static salt is never of much use, that's the only thing certain so far. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 20, 2017 at 15:08
  • $\begingroup$ right so the (pseudo)code is like PBKDF2(AES("userSuppliedPassword","const string key"),"const string salt") which is copied by the user, and stored in a config file, then when the project is run, it's run in reverse with the same const string key and const string salt. Seems pointless to me $\endgroup$
    – Austin_Anderson
    Commented Sep 20, 2017 at 15:27
  • $\begingroup$ Not sure I grasp your description correctly. So far I understand from the pseudo-code in your comment that AES is obviously only used to create a combined password (user key, encrypted with fixed key) to feed that to PBKDF2 together with a seperate salt. So far, it all makes sense from a cryptographic point of view. But you lost me when writing when the project is run, it's run in reverse… as KDF's usually don't tend to be reversible. Am I correct to assume that you meant to say – upon each startup, the PBKDF2 function recreates the same derived password using the stored user key and salt? $\endgroup$
    – e-sushi
    Commented Sep 20, 2017 at 16:38
  • $\begingroup$ ah I missread the code, it's using the pseudo code I posted to generate the actual key to encrypt with, then encrypts and decrypts with that, but the fact remains it's the same salt and aes key each time for encryption and decryption $\endgroup$
    – Austin_Anderson
    Commented Sep 20, 2017 at 16:46

1 Answer 1

Reset to default
1
$\begingroup$

Obviously it would be easy to decrypt the password for any serious attacker, but it might help deter casual attackers. Instead of opening the config file in a text editor and finding the password they would have to decompile and decrypt it, or snoop the memory while it's running. It might also help to stop automated tools that may be searching the filesystem for documents containing things like "password=xxx".

Improve this answer
$\endgroup$
1
  • $\begingroup$ So basically it's security-by-obscurity, which helps against "noob hacker" that can't hack your application, but somehow could if you didn't do this magic = Case that never happens. $\endgroup$
    – axapaxa
    Commented Feb 18, 2018 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.