3

I am required to utilize an old version of ClearQuest 7, and the only APIs that are enabled in our installation are for VBA (Excel) and RatlPERL. (The REST API isn't an option for us - although it suffers the same cleartext credential problem.)

I've written a ratlperl script that executes queries into the defect database, and produces csv output. Note that ratlperl requires cleartext user credentials for authentication.

ratlperl query.cqpl -u %userid% -p %password% -q "%query%" -c %outfile%

That script is called from a Windows Batch file. When run from the Windows command line with no parameters, the batch file requests user credentials, but they can also be provided as parameters. 

query.bat %userid% %password%

I trigger daily queries, with the user credentials passed as parameters for the batch file.

This all works well, but I'd rather not store the cleartext password in this way. The registry would be one possibility, but anyone with access to the machine would have access to those credentials.

How can I store these credentials in a somewhat secure way?

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
  • 3
    How much control do you have over the box? Is it other users you have to protect against, or other administrators? – Sobrique Jun 30 '15 at 15:42
  • @Sobrique - currently my personal laptop, so locked down. However, I intend to move this to a departmental service machine with shared access, where all users have admin privileges. It's not that I don't trust _them_ with my bug-system credentials, but the door is open (figuratively speaking). – Mogsdad Jun 30 '15 at 17:04
  • 1
    If everyone has admin, then there just isn't much to be done beyond hope you can trust them. Which does simplify the problem, at least.. – Sobrique Jun 30 '15 at 17:30

2 Answers2

3

There's two things to watch out for. One is having your process list "show up" the auth credentials. Particularly on Unix - if you run ps it'll show you the arguments, which might include a username and password. The way of handling this is mostly 'read from a file, not the arg list'. On Unix, you can also amend $0 to change how you show in ps (but that doesn't help command history, and it's also not perfect as there'll be a short period before it's applied).

The other is - storing the data at rest.

This is a bit more difficult. Pretty fundamentally, there aren't many solution that let your script access the credentials that wouldn't allow a malicious user to do so.

After all, by the simple expedient of inserting a print $password into your script... they bypass pretty much any control you could put on it. Especially if they have admin access on your box, at which point... there's really nothing you can do.

Solutions I'd offer though:

Create a file with (plaintext) username and password. Set minimum permissions on it. Run the script as a user that has privileges, but don't let anyone else access that user account.

That way other people can 'see' your script (and may need to to run it) but can't copy it/hack it/run it themselves.

I would suggest sudo for this on Unix. For Windows, I'm not sure how much granularity you have over RunAs - that's worth a look, or alternatively have a scheduled task that runs as your service account, and picks up 'request files' for processing that can be generated by anyone.

Sobrique
  • 52,974
  • 7
  • 60
  • 101
  • Some good thoughts there, thanks. This is in windows presently, although the perl scripts should be able to run as-is under linux. Squeezing a linux box out of our IT department would be a huge task on its own, unfortunately. I will look at mods to pick request files, though. – Mogsdad Jun 30 '15 at 16:59
1

As the level of security doesn't need to be so high, perhaps consider to create a simple exe? The password could possibly be read out of the memory somehow, but I guess this way creates a big enough barrier.

Or something like this could be helpful?

http://www.battoexeconverter.com/

HTH

Jos Lemmerling
  • 91
  • 5
  • Another interesting idea. Tried it, but while compiling the bat to an exe hid the details of the bat file nicely, the weakness was that while the perl code is running the credentials are visible. +1 for out-of-the-box thinking! – Mogsdad Jul 01 '15 at 02:02
  • It has the same limitations though - your executable will have to have the credentials embedded 'somehow' for it to extract. It's slightly more difficult to disassemble, but only slightly. It would be unwise to rely on this sort of obfuscation for security. – Sobrique Jul 06 '15 at 10:01