Insecurity of Keychain Access: "secure" notes visible during authentication

Question

Sorry if this has been discussed before, but I'm not keen on wading through 137 pages of discussions.
I recently discovered Keychain Access' ability to create "secure notes," and thought this would be a wonderful way to keep my serial numbers, bank accounts, and other sensitive information secure.
However, I just tried to actually decrypt this information for the first time, and was rather shocked. When you attempt to open a secure note, and select the "show note" checkbox that prompts the "Deny / Allow Once / Always Allow" dialog box, the dialog box contains the "secure" information from the note!
In my example, which you can see here (http://www.justinreese.com/media/images/secure_bbedit.png), the entire text of the note is included in the dialog, previous to any password authentication. Of course, because I'm reusing the login keychain, I understand that it's already been decrypted upon logging in; however, I was under the impression that using Keychain Access to store secure notes and other passwords offered a secondary level of protection, and that even if someone were able to compromise my system while I was logged in, at least that sensitive data would remain secure (the way a dedication application such as Wallet or Yojimbo would do it).
So... is this a bug, an oversight, or simply my own poor planning in using the login keychain to store secure information?
Thanks to all.
17" Powerbook G4/1.5Ghz   Mac OS X (10.4.6)   Stock + 1GB of RAM
17" Powerbook G4/1.5Ghz   Mac OS X (10.4.6)   Stock except 1.5GB of RAM

Answer 1

My suspicion is that when you created the note, in the "name" field, you used "paste" intending to paste "BBEdit 8 Registration". However, if the clipboard at the time had contained multiple lines, the "Name:" field would then contain the entire contents (Owner Name, Email Address, etc), although it might not be immediately apparent since the main "Keychain Access" window would only display the first line. However, when asking for authentication, the full "Name" is displayed. This scenario is easy enough to replicate.
The odd thing is that even if the "Name:" is subsequently edited to remove the extra lines, the "authentication dialogue" seems to continue to ask for authentication using the "old" name... it's probably being cached somewhere but I haven't been able to track it down.
So in this case, I would call this "user error" for putting "secure" info in an "insecure" field in the first place, but there is definitely some sort of bug / oversight / slopiness in that the authentication dialogue doesn't update - so in effect it is asking you to authenticate for one thing, when in reality it is authenticating something that might have a completely different name. That sort of thing might open up "spoofing" opportunities, but for a user's personal keychain, I would suspect that anyone that can get close enough to do something with it would have opportunities to do far worse. Still, it can't be a good thing...