Comment by davidgh | Hacker News Reader

Comment by davidgh | Hacker News Reader

Parent Full thread

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action.

As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away.

As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app.

I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away.

I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Credit card info, passwords...

You're already submitting it to the server. It's no less secure sending it back if there's a problem.

This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary.

Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server.

TL;DR it is much, much less secure to do this.

> This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad

What are you talking about? Who said anything about plaintext? And no one said anything about sessions either.

If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free.

If you're submitting to the server over https then it's definitely no less secure to return the data.

Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors.

I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.

Security operates in layers. TLS isn't the end-all, be-all for security. It's one layer that prevents a category of attack vectors. Every extra unnecessary sending or storing of sensitive data is an attack vector.

Again, we're not storing anything. And in our case TLS is the layer we're using for protecting our data in-transit. You rely on it as a client when you send the form to the server.

Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?

What he's suggesting is that you never send the password to the server, you only send the hash.

The password itself never leaves the client, and never hits the network.

Password itself is an exception, I agree with you since you don't need the plain value at all, you can get away with comparing hashes. But how about CC data?

Couldn't you do the same? Hash-spaces are segregated by zip codes (hash(zip) is the key to buckets) and then hash the credit card and cvv; compare to verify

Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form

I'm not sure you can. If a site asks you for CC and CVV data it should already be PCI compliant, say a payment processor. Don't they need the plain text CC and CVV to be able to bill it, if it's a first time user? How can the client send a hash, compare it to what?

I'm really curious about how you see this working, I can't understand how you can forever obfuscate your CC info. I assume at some point the server needs your plain data.

I've personally never worked with payment processors, but I don't see why your intermediate servers would need to have it plaintext

To the payment processor, they'll always have the cc/cvv info, or rather, the hash of it, to verify with. If they don't have it, then I imagine the user doesn't have a valid cc. (How can you have a VISA cc that visa doesn't know about? If its a valid cc, eventually we have to hit someone who knows it...)

For creation of the CC, its entirely done offline atm isn't it? And since its basically just a shared secret, you could do the whole diffie helman physically.. but anyways

So then on your side, as some kind of store, it should be the same as passwords. The payment processor tells you the hash function to use, and you use it client side, and the processor verifies.

Alternatively, you send the user to the someone else (ie redirect to paypal), who does the same thing.

It doesn't seem at all necessary to me that your cc/cvv actually leaves your machine in plaintext. Of course, they may be sending plaintext for some reason, but I don't see an obvious reason why they should

Reply on news.ycombinator.com