Is retaining failed credentials legal?

[Markos Fragkakis]

Speaking of strange client requirements, one requirement they came up with today is to retain attempted username/passwords that failed.

Does anyone know if this is even legal? It seems reasonable to me that this might be illegal, as these credentials could be valid for other services the user uses. However, I could not find any EU legislation forbids this (I am based in Europe).

I realize that the legality or not of this may is probably relative to the country, so to make it more specific, does anyone know if it is (il)legal in Europe of the US?

[Kevin Wright]

That depends on what you mean by "retain".

Personally, I *hate* websites that force me to type in my password again because some other field failed validation.  For bonus annoyance points they test the captcha as well.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/W24TkW17ESQJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Markos Fragkakis]

I mean keeping in the database the attempted pairs of username/password that failed, and the user that attempted them.

--
Sent from my iPhone

[Fabrizio Giudici]

On Mon, 14 Jan 2013 22:24:35 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> That depends on what you mean by "retain".

I suppose he means the credentials are logged, or stored somewhere not
just in order to re-render a page.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Graham Allan]

Sorry, I don't know if there are laws or not. However, I am curious,
what use case is this behaviour intended to address? I understand if
you can't talk about it, I'm just interested in what goes on some
people's minds :)

If you can't find a law, perhaps just pointing out the potential
damage of negative publicity around password leaks, such as with
LinkedIn[0].

~ Graham

[0] http://www.bbc.co.uk/news/technology-18338956

On 14 January 2013 21:30, Fabrizio Giudici

> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.

[Ryan Schipper]

As to the legality, I think the correct question is: is it legal to store the password (as entered or some derived form, such as a hash)? 

Auditing failed login attempts (the username, a timestamp, etc) is an extremely common practice - in fact, Australian information security standards require it and common professional security certifications (CISSP etc) recommend it. I'd be very surprised if it illegal to track this sort of information within the EU. These logs are invaluable in conducting internal fraud or security investigations. 

That said, why does the password (in particular) need to be tracked? I can think of a very good reason not to track it: mistyped passwords. Consider how many times you mistype your password. If a computer system were to track my mistyped passwords, the database containing those would become a treasure trove for internal fraudsters.

I can't think of a sane security professional that would recommend tracking passwords in this manner - usernames and timestamps, absolutely, but not passwords.

PS. As usual, if you or your client are legitimately concerned, you should be consulting a practicing lawyer, not a list of Java doods. =)

-- Ryan

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Josh Berry]

I thought it was actually best practice to not even record the username.  Since a very conceivable mistake is to forget to tab over to the password field and then submit the form after typing username and password into the same field.  Perhaps only storing a hash might be safe.  

Regardless, does seem in the questionable category of even being useful, and instead just opening you up to further attacks.  I view it (in what I do not think of as a controversial view) as the username/password of users is actually valuable information.  As much so as credit card numbers.  Treat it as such.

(None of this is to say Ryan's answer is incorrect in any shape form or fashion.)

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Fabrizio Giudici]

On Mon, 14 Jan 2013 23:16:56 +0100, Ryan Schipper <psych...@gmail.com>
wrote:

> think of a very good reason not to track it: mistyped passwords.

... and as it has been already said, the fact that sometimes you swap your
username with the password. Which means that it's not only the password
that creates a problem when ends up in the log, but even the account name.

It's absolutely funny that you use hashes for building a system where
nobody but the user knows the password, and then the password ends up in a
log.

[Markos Fragkakis]

Hi all and thanks for the answers. 

The client took changed the requirement to logging the username / timestamp / login outcome. I'm sorry but I still haven't found the reasoning behind the requirement, when I do find out I will come back with an update. 

In any case, I'll try to communicate through my manager that attempted usernames might actually be or contain the password (or a mistyped password). 

Irrespective of the specific case, retention and logging of this kind of data sure opens a lot of security issues and needs to be handed carefully.

Thanks again.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Ryan Schipper]

Definitely the more purist approach. Less value for investigations.

In reality, Most organisations choose to take the chance on this in order to assist investigations when necessary

Smart software could also check whether the username is valid prior to including it in the log. Though this could open the possibility of timing attacks. The whirling dervish of security strikes  again....

[Rakesh]

tomorrow I decide to build a website that takes credentials.

I don't see if I choose to store the passwords or not, encrypted or not, is governed by some law. Its not enforceable.

Obviously, as a professional, I would want to make sure the decision I make does not lead to issues with my business.

When Sony was hacked, no government prosecuted them (I believe).

Rakesh

[Casper Bang]

On Monday, January 14, 2013 11:16:56 PM UTC+1, Ryan Schipper wrote:

That said, why does the password (in particular) need to be tracked? I can think of a very good reason not to track it: mistyped passwords. Consider how many times you mistype your password. If a computer system were to track my mistyped passwords, the database containing those would become a treasure trove for internal fraudsters.

The problem is that, as a user, we have no idea what goes on on the server side of a secure connection we POST credentials to. We have to entirely trust the developers behind any given service, which can be hard to do at times.

If HTTP included a mechanism to automatically hash the password (one can hand-code this today, but it's not common and it's not visible to the user of a service), this whole issue of password logging and theft would go away. The mechanism should probably include an optional salt, so that even attacks using rainbow tables on stolen log files would be useless.

This would naturally require a second hash+salt on the server side, so different representations of the password exist in 3 different realms; client/browser (password), transport/http (hash(password+SALT)) and server/database (hash(hash(password+SALT))+SALT).

[Jim Cheesman]

Certainly is enforceable, there are two clear scenarios that come to mind immediately (there may well be more):

1. A hacker gets into your system, and publishes a complete dump of your database.

2. Suspected crime, and a government agency (with appropriate warrant) gets a copy of your database. 

In both cases your database is no longer in your hands, and your password policy is on display. The very least you should do is store password hashes, which provide at least some minimal security both for your users and CYA. 

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Rakesh]

And who exactly is going to do the prosecuting and which law was broken?

The closest thing I know is UK-specific, banks have been fined for losing customer data under UK Data Protection Laws. No one goes to jail though.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/XAIX9KBuS8cJ.

[Rakesh]

but certainly there is no law that saya password must be stored this way or that and if you don't you go to JAIL!

[Josh Berry]

On Thu, Jan 17, 2013 at 3:20 AM, Casper Bang <caspe...@gmail.com> wrote:

On Monday, January 14, 2013 11:16:56 PM UTC+1, Ryan Schipper wrote:

That said, why does the password (in particular) need to be tracked? I can think of a very good reason not to track it: mistyped passwords. Consider how many times you mistype your password. If a computer system were to track my mistyped passwords, the database containing those would become a treasure trove for internal fraudsters.

The problem is that, as a user, we have no idea what goes on on the server side of a secure connection we POST credentials to. We have to entirely trust the developers behind any given service, which can be hard to do at times.

If HTTP included a mechanism to automatically hash the password (one can hand-code this today, but it's not common and it's not visible to the user of a service), this whole issue of password logging and theft would go away. The mechanism should probably include an optional salt, so that even attacks using rainbow tables on stolen log files would be useless.

I do not see how basic hashing of the password is worth much.  It simply changes your password from what you typed, to something hashed off of what you typed.  Right?  I suppose you could have some sort of handshake to determine the salts on a per connection basis, that would help.  But, at this point, it sounds like you are describing a poor attempt at recreating HTTPS.

[Josh Berry]

On Thu, Jan 17, 2013 at 4:40 AM, Rakesh <rakesh.m...@gmail.com> wrote:

but certainly there is no law that saya password must be stored this way or that and if you don't you go to JAIL!

Can't disagree here.  I would think a certain amount of neglect would simply open you up to civil liabilities.  Consider if a bank handed over your money to someone that just said they were you with no proof.  I would expect you have some legal options at that point.

[Casper Bang]

I do not see how basic hashing of the password is worth much.  It simply changes your password from what you typed, to something hashed off of what you typed.  Right?  I suppose you could have some sort of handshake to determine the salts on a per connection basis, that would help.  But, at this point, it sounds like you are describing a poor attempt at recreating SSL.

HTTPS can prevent man-in-the-middle attacks, but it can not in any way be used to guarantee that your entered credentials is not logged or stored improperly at the receiving end. My point is that, as long as everyone agrees about the algorithms, whether you do hash(password) on the server or hash(hash(password)) split between the client and the server, is irrelevant in practice... but only the latter mechanism guarantees that no clear-text password ever enters the remote system. This could be build into HTTP (added to RFC).

[Fabrizio Giudici]

On Thu, 17 Jan 2013 22:38:32 +0100, Casper Bang <caspe...@gmail.com>
wrote:

> HTTPS can prevent man-in-the-middle attacks, but it can not in any way be
> used to guarantee that your entered credentials is not logged or stored
> improperly at the receiving end. My point is that, as long as everyone
> agrees about the algorithms, whether you do hash(password) on the server
> or
> hash(hash(password)) split between the client and the server, is
> irrelevant
> in practice... but only the latter mechanism guarantees that
> no clear-text password ever enters the remote system. This could be build
> into HTTP (added to RFC).

In the end, it wouldn't be better to build web systems that only accept
client SSL certificates instead of passwords?

[Josh Berry]

On Thu, Jan 17, 2013 at 4:38 PM, Casper Bang <caspe...@gmail.com> wrote:

I do not see how basic hashing of the password is worth much.  It simply changes your password from what you typed, to something hashed off of what you typed.  Right?  I suppose you could have some sort of handshake to determine the salts on a per connection basis, that would help.  But, at this point, it sounds like you are describing a poor attempt at recreating SSL.

HTTPS can prevent man-in-the-middle attacks, but it can not in any way be used to guarantee that your entered credentials is not logged or stored improperly at the receiving end. My point is that, as long as everyone agrees about the algorithms, whether you do hash(password) on the server or hash(hash(password)) split between the client and the server, is irrelevant in practice... but only the latter mechanism guarantees that no clear-text password ever enters the remote system. This could be build into HTTP (added to RFC).

I guess my problem is with the "everyone agreeing on the algorithms."  If it is just a hashing system where everyone agrees to just send the hash instead of the typed text, doesn't this simply shift what the thiefs are looking to steal into the hash?  And... since that is the first phase of creating a rainbow table, I'm not sure it actually changes anything.

I am curious if you have readings/links that have this idea fleshed out more.  I hate to feel like I'm just rejecting it.  That is not my intent.  I do side with Fabrizio, though.  Certs seem like they would be much stronger.

 

[Josh Berry]

This headline reminded me of this thread.  Is specifically about the Data Protection Laws you mentioned, I believe.

http://arstechnica.com/security/2013/01/sony-fined-395000-for-2011-hack-of-its-playstation-network/