View Source - Encrypting form fields.

[Guest]

Hi,

We have a "Change password" screen, that will be populated with the old passwords (in a textbox), my client says that during displaying the same, one should not able to goto view source and see it.

I tried Encrypt function like Encrypt(form.txtpassword,......) but when submit the form, the encrypted values gets updated in the db (rather than the actual ones).

So, All I need is to prevent my users from view the password through "View Source", but they should be given a way to change it and update it in the databse.

How to accomplish this?. Any ideas?.

[tooMuchTrouble]

why show the password at all?

[Guest]

Hi Paul,

Thanks for the answer.

I agree with you.. But unfortunately they won't allow us to change the existing system/screen design.

Any other ideas?.

[tooMuchTrouble]

if you're displaying the old password as clear text, then i can't see why

they're worried, it's already too late. if it's obscured somehow, then

substitute ***'s or whatever for the old password when you drag it out of the db.

also if they're not letting the system be modified in any way, then all of this

is kind of moot anyway.

[Adam Cameron.]

if you're displaying the old password as clear text, then i can't see why

they're worried, it's already too late. if it's obscured somehow, then

substitute ***'s or whatever for the old password when you drag it out of the db.

You do not have a very devious mind Paul.

Consider this scenario.  You are logged-in to your application, working away.  You get up to go get a coffee.  I come over to your terminal and go to the password-change screen, go view-source, and now I have your password.

I don't think the issue here is to protect the legitimate user from being able to find out their own password 😉

--

Adam

[Adam Cameron.]

The existing system, or the existng screen design?

If it's the former... why are we having this conversation, other than as something to chat about?  Even if you come up with a solution, you can't change the system so you can't implement it.

If it's just the UI that can't change, all you need to do is to stop populating the password field with the actual password!  Because password inputs visually obscure the value of the field, it doesn't matter what value you put in there.  On the action page, only update the password value if it's NOT the placeholder text you populate the password field with by default.

--

Adam

[Guest]

Thanks guys for your answers.

@ Dan, Its there (infact that is the problem!.. I just want to hide that someway).

@ Ian and @ Adam,

I must say that the change is to be done with the existing screen design, but we are not allowed to take off that text field which is currently showing the password in that page (as well as in the view source)

We need to retain the screen design as it is, and we need to protect that password value from the "View Source".

How to do this?.

Please help.

[Adam Cameron.]

Did you read the last para of my posting???

--

Adam

[Dan_Bracuk]

If the password is showing up after you submit the form, find out why.  It shouldn't be necessary.

[ilssac]

S C O R P I O N wrote:

@ Ian and @ Adam,

I must say that the change is to be done with the existing screen design, but we are not allowed to take off that text field which is currently showing the password in that page (as well as in the view source)

We need to retain the screen design as it is, and we need to protect that password value from the "View Source".

How to do this?.

You write you own browser and then write your own standard that would replace the current HTTP and HTML standards created by the w3c.  You would then need to get every user to connect to your web site using your browser and have the server and their browser and everything in between use your standards.

If the text is being displayed by the browser in a text field, then that text is in the HTML source.  How do you expect to put something in the source that is encrypted and have the browser display it, unencrypted.  HTML does not work that way.

[Owainnorth]

Amen.

I'm afraid that what you're asking for is completely nonsensical - an existing password should never be sent to a browser unless you *want* the user to be able to see it.

Why do you need to send it to the browser at all? As mentioned previously there's no need to do this, and unless you can change the code that sends it there you're not going to get anywhere.

O.

[ilssac]

If something is one the screen then it is in the source?  I just don't picture what you are trying to accomplish here.  The little dots or stars that a browser puts into a password field are for people looking over your shoulder while you type passwords.  They don't protect the data from the system in any way.

[Dan_Bracuk]

Run your page without encrypting anything.  Look at the html source code in your browser.  Is the password there?

[A***]

I tried Encrypt function like Encrypt(form.txtpassword,......) but when submit the form, the encrypted values gets updated in the db (rather than the actual ones).

If you are satisfied with this initial approach all you need to do is decrpyt the password before it is passed into the database.

<cfoutput>

      <cfset form.password = "testing" />

      Original password: <strong>#form.password#</strong><br />

      If desired, choose your algorithm (let's say DES) and generate your key:<br />

      <cfset myAlgorithm = "DES" /><cfset myKey=generateSecretKey("#myAlgorithm#") />

      On your login page you encrpyt your password:

      <cfset form.password = encrypt("#form.password#", "#myKey#", "#myAlgorithm#")><br />

      Encrpyted password: <strong>#form.password#</strong><br />

      Then on your action page, before you pass the data into your database, you just decrypt:

      <cfset pwdReadyForDatabase = decrypt(#form.password#,"#myKey#", "#myAlgorithm#")><br />

      You end up with your old password in the database: <strong>#pwdReadyForDatabase#</strong>

</cfoutput>

[Guest]

@ Ian Skinner @ OwainNorth,

Guys,

I understand this is not a proper requirement, and whatever you suggests seems valid for me.

But understand, I cant go and suggest these things to my business. I have to see for a viable solution within the resources I've got.

And when we come to forums, we expect some answers / suggestions. But I hope answers like, "You write your own browsers"  and "Nonsensical Question"  can be avoided, because it will certainly discourage the newcomers / learners like me.

Appreciate all your help!..

[ilssac]

S C O R P I O N wrote:

And when we come to forums, we expect some answers / suggestions. But I hope answers like, "You write your own browsers"  and "Nonsensical Question"  can be avoided, because it will certainly discourage the newcomers / learners like me.

Appreciate all your help!..

But sometimes newbies ask questions for which that answer is "If you are asking to do that, then you do not understand the technology you are working with, becuase that is impossible do to the way that things work".

Now seeing you respond faverable to the above situation where you can display an encrypted password, that begs the question, why display anything at all.  Since you are displaying the password in a form no human is going to understand, what purpose is there in doing so.

This may be a case where what you really need to do is store the old password in a session variable or some other server resource like that to be used later on during the form action processing.  And not bother delivereing or displaying it to the user.

That's the way I would approach what I now think your are trying.

But I am going to close here with the statement that I am still very unsure I understand what you are really trying to accomplish.

[Guest]

Thanks A***,

You answer gives me an alternate way of accomplishing my requirement. I will surely give it a try.

[Dan_Bracuk]

If you want to be thorough, and this might be what your boss really meant, you won't cache the page where password was displayed.