Storing salted hash details

[eluser]doubleplusgood[/eluser]
Hi there,

I'm creating a user account system and one of the pages that a user will see when they login is an information page describing how to access our ftp server, along with a username and password.

Obviously I want to store the password in the database using a salted hash method, which I can do. But I wondered if it is technically possible to display the password back to the user (on a logged in page) so that they can copy it to enter it into FileZilla, rather than displaying the salted hash back to them?

Thanks.

[eluser]rogierb[/eluser]
Only when you use an encryption method which can be decrypted.

[eluser]doubleplusgood[/eluser]
Heh, I thought it might be a silly question.

[eluser]rogierb[/eluser]
Nah, not silly, I've thought about it aswell using mcrypt. But is just isn't as safe as proper hashing.

[eluser]BrianDHall[/eluser]
Well, one thought here is if the password is being used on FTP it is already stored and going to be transmitted in clear text - so its security is already compromised. The general rule is FTP passwords should be different than any other passwords due to their relative insecurity. FTP is actually often turned off entirely in PCI Compliant applications that store credit card data precisely for this reason.

If you seek PCI Compliance you would want to make your application login and FTP passwords different, but it would be perfectly acceptable to use reversible encryption (such as with mcrypt) to store the FTP password and echo it back to the user on their login page (which of course should be delivered over SSL).

If you don't seek PCI Compliance then for simplicity I would simply suggest when you store the users password you retain your salted hashing primary method, but at the time of storage you save a reversible encryption version in a separate row of your user table. CI's Encryption library is very handy to make this process easier.

FTP is one of those things that already has so many potential vulnerabilities that storing a reversible encryption version of a password using a 128-512bit cypher key is the least of your problems

[eluser]doubleplusgood[/eluser]
Hey Brian,

Thanks for information about the PCI Compliance. This is all for the client that I had spent several days building an application for their clients to login and upload files ready for printing and then yesterday told me that they just have an FTP server that they create accounts on and give that out to the user to upload and download files from.

So it pretty much made the majority of the application that I was building useless. They wish to keep the FTP because it is much faster uploading and downloading from there. Which I agree with as uploading a large file through a web form using a CodeIgniter app does seem to take a while.

So now they want the user to create an account on the website to pretty much just see an instructional page where they can find their FTP Username, Password and Hostname. All rather tedious as the user is creating an account to basically see some other account information. What fun.

[eluser]BrianDHall[/eluser]
Well good lord, that sucks. If you want to 'sell work', you might talk to them about using your system to actually create and manage the FTP accounts. Also point out that many companies have proxies and firewalls that block all FTP traffic, and some people don't have proper FTP clients - or for that matter even know what FTP is. For them it would be nice to offer a simple form option, and PHP/CI comes with plenty of FTP functions that would allow them to only use FTP for their purposes but allow everyone else to use either FTP or HTTP.

This also paves the road for future order tracking, order/file history, and so forth.

The biggest print resellers in the world all offer website-based file uploads, such as 4over.com, the god-awful bastards at vistaprint(for-satan), partnerprinting.com, etc. I've been in printing for years so I know how they can be, they've used the tech so long they think everyone should know how to use it properly - but dropping the barriers of doing business with them must be why they want to offer a website, so they really should consider doing more than just a reminder/instruction page.

If you can convince them of it, of course

[eluser]jedd[/eluser]
If they believe FTP is faster (than what?) then you can borrow my clue stick to hit them over the head with.

Use ssh - specifically scp. Using the compression flag you'll instantly get better performance than FTP provides. Using passwordless authentication you'll also waste less time doing handshaking than FTP, plus almost as a side-benefit you get actual real-world security. You'll also find any weird proxy and firewall and NAT problems you used to have suddenly cease to exist in a puff of single-port pulchritude.

FTP really does blow goats. It's disturbing to see anyone use it in a commercial environment these days (by 'these days' I refer to anything post 2000).

[eluser]doubleplusgood[/eluser]
Hey Brian, I was actually reading up on the FTP Class this afternoon to see how it could be used. The main point for the print reseller seems to be that uploading via ftp is a lot faster for them to send files back to the client.

I was thinking that the FTP Class could be used in such a way that it would read the contents of the directory and output to the user in the web front end. That way, the print reseller could still just use ftp transfer using something like FileZilla and the files would automatically get listed on the revelant client's account page when they log in to the site.

The print reseller would probably have to initially create part of the website account for their client, most likely including the ftp username, ftp password and the name of the unique directory on the ftp server for that client, so that this could be used dynamically to output only those files in that users' ftp directory.

[eluser]doubleplusgood[/eluser]
Hey jedd,

Thanks for the tip about scp and compression flags. I'll get reading on those.

I tried my CI upload form and it took an age to upload a 60mb file to the server, even longer than uploading the same file to another print agency that does actually have an upload function on their website. I wasn't sure in that instance whether it was the server itself that wasn't performing well or if it was the CI functionality (either through what i had coded or the Uploader class).

[quote author="jedd" date="1256095938"]If they believe FTP is faster (than what?) then you can borrow my clue stick to hit them over the head with.

Use ssh - specifically scp. Using the compression flag you'll instantly get better performance than FTP provides. Using passwordless authentication you'll also waste less time doing handshaking than FTP, plus almost as a side-benefit you get actual real-world security. You'll also find any weird proxy and firewall and NAT problems you used to have suddenly cease to exist in a puff of single-port pulchritude.

FTP really does blow goats. It's disturbing to see anyone use it in a commercial environment these days (by 'these days' I refer to anything post 2000).[/quote]