jbard: I think you should reply to him with the evidence to the contray, so that it's clear that this isn't the case. He may well be being mislead and this kind of thing is likely to stop the site being decent ever unless he gains an understanding he is being fed the wrong information.

Please correct me if I'm wrong, but the fact they had the means to send the password out via a 'forgot password' email in plain text clearly suggests that they at least had the means to decrypt said "encrypted" passwords.

dontpanic42: Please correct me if I'm wrong, but the fact they had the means to send the password out via a 'forgot password' email in plain text clearly suggests that they at least had the means to decrypt said "encrypted" passwords.

This is the complete opposite of secure.

Oh the stories I could tell you about other large organisations doing just this who's information is a lot more sensitive than a little kiwi auction site....

dontpanic42: Please correct me if I'm wrong, but the fact they had the means to send the password out via a 'forgot password' email in plain text clearly suggests that they at least had the means to decrypt said "encrypted" passwords.

This is the complete opposite of secure.

Oh the stories I could tell you about other large organisations doing just this who's information is a lot more sensitive than a little kiwi auction site....

DonGould: That was my initial thought when we started to see log on errors showing up and MF posted about being able to see other peoples details after he'd logged in.

I wish them good luck getting that one sorted out if that's the case. The JDF that someone posted suggested to me that they weren't asking for people with proven experience in that space.

But the thing is that with any knowledge of how session management works in .NET, this sort of thing would not have happened. It's quite easy to either a) enable "sticky sessions" on your F5 BigIP LTMs or Citrix Netscalers, or b) enable ASP.NET State Server or SQL Session State support for the .NET application and have all the frontend nodes use the same data store and machine keys for session storage. It's scalability 101 for .NET application architecture. Coupled with the fact that they could recover your password - something that could have been improved upon by using ASP.NET membership providers for heck sake! - and it's clear that they did not pick a good team.

I've seen some really bright cookies in India (and 90% of the team I work with now are Indian and do an exceptional job) and I've seen some terrible ones (in my previous job, the Indian outsourcing provider screwed up so badly, they flew their developer to us in NZ to do the job properly!) so it's not necessarily even the outsourcing that's the problem, it's just the fact that... well, the people they chose to do the job didn't know what they were doing.

dontpanic42: Please correct me if I'm wrong, but the fact they had the means to send the password out via a 'forgot password' email in plain text clearly suggests that they at least had the means to decrypt said "encrypted" passwords.

This is the complete opposite of secure.

Oh the stories I could tell you about other large organisations doing just this who's information is a lot more sensitive than a little kiwi auction site....

LOTS and LOTs of sites do this.

One in particular I know about (Overseas) is a shocker. Also, the market incumbent should be careful about what they say on the topic too ;)