Bug #29453 Log After Fetching Schema shows passwords.
Submitted: 29 Jun 2007 21:58 Modified: 4 Feb 2009 14:52
Reporter: marc castrovinci (Basic Quality Contributor) Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Migration Toolkit Severity:S1 (Critical)
Version:1.1.12 OS:Windows (XP PRO SP2)
Assigned to: Mike Lischke CPU Architecture:Any
Tags: log, password, show

[29 Jun 2007 21:58] marc castrovinci
Description:
When you use the Migration Toolkit your passwords for the source database and target database are shown under 'Advanced'.

How to repeat:
Pick a source (Mine was Oracle).
Enter information for DB. (system user in Oracle is REQUIRED to fetch schema)
Click 'Next'

Pick a target. (Mine was a local 5.0.40 copy)
Click 'Next'.

On the Connection Process page click 'Advanced'.

You will see something similar to:

Connecting to source database and retrieve schemata names.
Initializing JDBC driver ... 
Driver class Oracle Thin JDBC Driver using SID
Opening connection ... 
Connection jdbc:oracle:thin:system/passwod@myhost.com:1522:oradb6
Fetching schemata list.
SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME
Return schemata list.
Schemata names retrieved successfully.
Initializing JDBC driver ... 
Driver class MySQL JDBC Driver 5.0
Opening connection ... 
Connection jdbc:mysql://localhost:3306/?user=root&password=root&useServerPrepStmts=false&characterEncoding=UTF-8
Getting version information ... 
Initializing JDBC driver ... 
Driver class MySQL JDBC Driver 5.0

As you can see you password is DISPLAYED FOR ANYONE TO SEE. So if you save your connections if someone gains access to your computer they can just do the following and they have now seen your source and target db passwords. This is terrible if someone got your system user password for Oracle.

Suggested fix:
Have the software change the passwords to ******* in the display.
[30 Jun 2007 1:23] MySQL Verification Team
Thank you for the bug report. Verified with SQL Server too.
[4 Feb 2009 14:52] Mike Lischke
Sorry, but I don't see a security problem here. The message log is not saved to disk so the only moment someone else can see the password is when you view this message log and someone else is looking over your shoulder.

Additionally, the connection string is by *intention* shown as it is sent to the server in order to fix problems when they arise.