Opened 12 years ago

Closed 12 years ago

#1354 closed bug (fixed)

It is possible to copy text from a password field (BTextView)

Reported by: ksmith Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

When a BTextView is set to HideTyping, it is still possible to copy the text from the BTextView and paste it into another app (i.e., StyledEdit) and read the password.

Attachments (2)

TextView.cpp.diff (321 bytes) - added by ksmith 12 years ago.
Proposed fix to this issue. It simply doesn't allow a user to copy text from a password field.
TextView.cpp.2.diff (671 bytes) - added by ksmith 12 years ago.
This patch uses the GetString method from the TextGapBuffer to obtain the "bulleted" text from the TextView if it is in password mode.

Download all attachments as: .zip

Change History (16)

Changed 12 years ago by ksmith

Attachment: TextView.cpp.diff added

Proposed fix to this issue. It simply doesn't allow a user to copy text from a password field.

comment:1 Changed 12 years ago by jackburton

Owner: changed from axeld to jackburton

How does BeOS behave here ?

comment:2 in reply to:  1 ; Changed 12 years ago by kaoutsis

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

comment:3 in reply to:  2 ; Changed 12 years ago by jackburton

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

comment:4 in reply to:  3 Changed 12 years ago by ksmith

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Sorry, I suppose I should have checked how BeOS behaves before proposing a patch. I will continue looking into this.

comment:5 in reply to:  3 ; Changed 12 years ago by johndrinkwater

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Can we deviate from this behaviour, why would anyone want to copy from a password field? Just ignore the request and leave clipboard untouched. Unless copying from one password field to another works (a really bad idea), it seems wholly stupid imo.

Changed 12 years ago by ksmith

Attachment: TextView.cpp.2.diff added

This patch uses the GetString method from the TextGapBuffer to obtain the "bulleted" text from the TextView if it is in password mode.

comment:6 in reply to:  5 Changed 12 years ago by ksmith

Replying to johndrinkwater:

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Can we deviate from this behaviour, why would anyone want to copy from a password field? Just ignore the request and leave clipboard untouched. Unless copying from one password field to another works (a really bad idea), it seems wholly stupid imo.

If copying is infact allowed, you will only be copying a string of bullets, not the password, so pasting into another password field would not work. I think its silly to allow copying from password fields because of this reason (Mac OS X does not allow copying from password fields. If you attempt to copy from one, an error sound will play). However, BeOS allowed it and I suppose they want Haiku to function in a similar way to BeOS.

comment:7 Changed 12 years ago by axeld

While we're indeed striving for BeOS binary compatibility, that does not mean we want to imitate all of its quirks. In this case, I'd think copying the dots is pretty much the stupidest thing that could happen (well, after copying the actual password, of course :-)). I think that's just a good opportunity to play the system beep.

comment:8 in reply to:  7 ; Changed 12 years ago by kaoutsis

Replying to axeld:

While we're indeed striving for BeOS binary compatibility, that does not mean we want to imitate all of its quirks. In this case, I'd think copying the dots is pretty much the stupidest thing that could happen (well, after copying the actual password, of course :-)). I think that's just a good opportunity to play the system beep.

second thought, (correcting my ... logic:)): you are right! there is no meaning copying the asterisks. The system should disallow the copy, play a system beep and may be display an alert message.

comment:9 in reply to:  8 ; Changed 12 years ago by jackburton

Replying to kaoutsis:

second thought, (correcting my ... logic:)): you are right! there is no meaning copying the asterisks. The system should disallow the copy, play a system beep and may be display an alert message.

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

comment:10 in reply to:  9 ; Changed 12 years ago by jackburton

Status: newassigned

Replying to jackburton:

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

So, I'll apply the patch, plus I'll let the system beep() in case one tries to copy from the password field.

comment:11 in reply to:  10 Changed 12 years ago by jackburton

Replying to jackburton:

Replying to jackburton:

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

So, I'll apply the patch, plus I'll let the system beep() in case one tries to copy from the password field.

Oh, I forgot: Should we also forbid copying text using the BTextView methods ? I mean: what should happen if the developer calls BTextView::Copy() from its code ? And what happens on R5 when the developer calls BTextView::Text() or TextLength() ? And how should we handle that case anyway ?

comment:12 Changed 12 years ago by stippi

I think the application that the text view is embedded in can be trusted. Therefor all methods to get the text should work. However, special care needs to be taken when messaging/scripting is involved. Especially when the reply target is not in the same team... :-)

comment:13 in reply to:  12 Changed 12 years ago by jackburton

Replying to stippi:

I think the application that the text view is embedded in can be trusted. Therefor all methods to get the text should work. However, special care needs to be taken when messaging/scripting is involved. Especially when the reply target is not in the same team... :-)

But if the app sends a B_COPY message, the message will come from the same team, no? I.E: in case the user hits ALT-C or ALT-X, it's the window which will handle the message. So we either forbid copying in every case (also when the Copy() (and Cut()) function is called directly) or never.

comment:14 Changed 12 years ago by jackburton

Resolution: fixed
Status: assignedclosed

Fixed in hrev22129. I opted for this solution:

When the Copy() or Cut() public methods are called, you get the real text. If they're called via scripting or via messages, you get a beep.

Note: See TracTickets for help on using tickets.