Passwords exposed in URIs
An application stores URIs to be used for file transfers via SFTP, FTP, FTPS and SCP. Many of these URIs contain passwords, for example:
sftp://someuser:[email protected]/
These URIs are visible to too many people. We cannot hide email addresses from these people.
A mini-language to get passwords out of URIs
Using a mini-DSL, we can specify the parts of the email address we don’t want to show:
sftp://someuser:<<CONFIG:customers/widgitco/password>>@host.example.com/
The program that does the file transfer would look for instances of this mini-DSL in the URI, parse them, look up the appropriate strings from restricted sources, and substitute those strings into the URI. For example, supposing that restricted source contains this key/value pair:
customers/widgitco/password: moresekrit
Then, after replacement, the URI should be:
sftp://someuser:[email protected]/
Each instance of the mini-DSL within the URI would be delimited with << and >>. Details of the mini-DSL between the << and >> would be free to vary in order to meet future requirements; the only requirement would be that it contain no >>.
This would achieve my goal of reducing the exposure of these passwords.
Is this mini-language fragile?
- Are there valid FTP/FTPS/SFTP/SCP URIs which will break this scheme?
- Are they at all likely?
- What mini-DSL is less likely to be broken by valid URIs?
6
- Are there valid FTP/FTPS/SFTP/SCP URIs which will break this scheme? Yes. Any user that has a password containing “<” or “> is likely to cause problems.
- Are they at all likely? Absolutely, since you don’t have any control over the passwords used by the users (presumably).
- What mini-DSL is less likely to be broken by valid URIs? None. Any un-escaped string substitution model, which is all this really is, is going to have problems.