So -- I might implement this eventually, as a spare-time thing. The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive, so there should be some forethought into how we'd want to handle session management and expiration for the REST API.

On 03/16/2012 03:40 PM, Christian Grün wrote:

I agree that plain md5 hashes are not state-of-the-art anymore (..well, for quite a while). If we update our storage, however, we should guarantee backwards-compatibility.

If anyone wants to dive into this.. Code patches are welcome.. ;) ___________________________

On Fri, Mar 16, 2012 at 8:59 PM, Charles Duffycharles@dyfis.net wrote:

...

Howdy --

I'm a bit concerned about storing password hashes unsalted -- compared to a salted hash, this makes a stolen database easier to retrieve user passwords from, dangerous if users use their passwords for other purposes as well.

Would salting (and perhaps stretching) the hashes be considered a reasonable feature to support in the future?

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

Dimitar,

Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.

I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.

On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov < Dimitar.Popov@uni-konstanz.de> wrote:

Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy:

...

So -- I might implement this eventually, as a spare-time thing. The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive, so there should be some forethought into how we'd want to handle session management and expiration for the REST

API.

One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)

Regards, Dimitar

Using SSL to encrypt passwords over-the-wire doesn't help with offline attacks against a compromised database (where the attacker copies the whole thing to attack at their leisure on machines they control), which is the scenario that hashing algorithms, as per this discussion, are intended to address.

I agree that SSL should be used -- any responsible user of the BaseX REST API should already be putting it behind stunnel or a similar proxy adding SSL support if they don't already have other appropriate measures in place.

On Sat, Mar 17, 2012 at 6:26 PM, Dimitar Popov < Dimitar.Popov@uni-konstanz.de> wrote:

**

Hi,

I admit I used "authentication" in the wrong way; what I meant is "authentication with username/password". That is, I consider the lack of https support a serious obstacle for secure authentication with username/password.

Regards,

Dimitar

Am Samstag, 17. März 2012, 15:58:55 schrieb Charles Duffy:

Dimitar,

Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.

I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.

On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov < Dimitar.Popov@uni-konstanz.de> wrote:

Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy:

...

So -- I might implement this eventually, as a spare-time thing. The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive, so there should be some forethought into how we'd want to handle session management and expiration for the REST

API.

One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)

Regards, Dimitar

[...] The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive [...]

I agree, performance is very essential here. What about using SHA-2? Christian

Howdy,

On Mar 17, 2012, at 14:54 , Charles Duffy wrote: [...]

Unfortunately, the goals of security and performance are quite diametrically opposed here

Yes and no... If you're allowing people in, they can easily destroy your system('s performance) in any number of ways.

-- using something fast enough that we can afford to perform authentication attempts very frequently means that an attacker can more easily afford to build a rainbow table.

Indeed. Though there's a natural separation between full-blown authentication and e.g. per-action access-verification.

Using more salt (the former 2-byte tradition is no longer remotely practical) makes these tables more expensive, and I'm not sure I _completely_ agree with John Mitchell that the conventional approach is completely broken, but he *does* have a point.

What's your threat and risk models is the fundamental question. People tend to just reach for simplistic solutions and assume that they (don't need to) understand the implications. Alas, history has shown that to be a poor decision.

This is why I'd lean towards a session-token approach, where we're willing to make authentication a fairly expensive operation (with bcrypt, the level of expense is a user-tunable operation, which is a quite desirable feature), but do it less frequently rather than once-per-operation.

I strongly concur.

Note also that there are a few different aspects of this that people may be confusing/conflating... * Protecting the user credentials for long-term storage in the database itself. * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. * Creating a decently secure communication channel.

bcrypt with it's normal cost-factor is a Very Good Idea(tm) for the first issue.

TLS/SSL is pretty much the only way to do #3 that's widespread for normal web use.

There's lots of options and variations that one can do in terms of #2. This goes back to the question of threat/risk models. I.e. do you just want a super-fast opaque token that you can lookup in the currently-active-session store? Or do you need to additional checks to make sure that token is only being used by the same client that it was issued to (i.e. being able to incorporate checks against things like mac-address/ip/blahblahblah).

Another factor that people should note in all of this is that even "relying" on TLS is quite expensive. Terminating TLS/SSL connections on each of your own servers can reduce performance 5-30X IME (but to be clear, I think it's a mandatory cost to pay if your doing HTTP services). Not that offloading that has it's own costs depending on how that's done... whether that's via a software or service based. For example, Amazon ELB can now terminate TLS for you but it's performance is wildly and unpredictably erratic.

Finally (I promise I'll shut up... :-), if you're putting services out on any sort of relatively open network, it's a very good idea to put some thought into addressing at least some basic anti-Denial-Of-Service capabilities if availability matters.

Hope this helps, John

Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell:

Note also that there are a few different aspects of this that people may be confusing/conflating...

• Protecting the user credentials for long-term storage in the database itself.
• Creating security tokens for the (relatively) high-speed access verification on a per-request basis.
• Creating a decently secure communication channel.

Hi all,

Now, since I've finally undestood what this thread is about ;) I have two suggestions, regarding the second point:

1. If opening a database connection is slow (in our case because of slow authentication), then a wide-spread solution in the J2EE world is the use of connection pools.

2. Another alternative which comes into my mind is encrypting the whole password file with a "slow" encryption algorithm (we could even use Java Crypto API, since we already use it for the XQuery crypto API). On startup, basex will decrypt the file once, an the store the "quick" password hashes in-memory.

Regards, Dimitar

Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy:

On 3/18/2012 6:09 AM, Dimitar Popov wrote:

...

Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell:

...

Note also that there are a few different aspects of this that people may

be confusing/conflating...

...

...

• Protecting the user credentials for long-term storage in the database

itself.

...

...

• Creating security tokens for the (relatively) high-speed access

verification on a per-request basis.

...

...

• Creating a decently secure communication channel.

Hi all,

Now, since I've finally undestood what this thread is about ;) I have two

suggestions, regarding the second point:

...

1. If opening a database connection is slow (in our case because of slow

authentication), then a wide-spread

...

solution in the J2EE world is the use of connection pools.

The REST interface uses credentials from the individual HTTP requests for the backend database connections.

So -- how do you keep a persistent pool, while still authenticating each HTTP request against the backend database's password store, and make it fast?

If you use session auth tokens, you can do it -- keep your connection pool tied to your session pool -- but I don't know that Christian has said that he considers that an acceptable solution as of yet.

Caching accepted username/password pairs in RAM, and maintaining a separate pool using the credentials for each such pair, would _work_, but it would mean that you'd have to be careful not to let the memory that information is stored in get swapped to disk -- writing users' passwords to disk, even by way of the OS's swap operations, being a serious no-no.

The pairs username/password can be, of course, hashed and additionally, swap partitions can be encrypted, if such a level of security is required.

...

2. Another alternative which comes into my mind is encrypting the whole

password file with a "slow" encryption

...

algorithm (we could even use Java Crypto API, since we already use it for

the XQuery crypto API). On startup, basex

...

will decrypt the file once, an the store the "quick" password hashes in-

memory.

How do you store the key for the "slow" encryption? If your database-startup routine has permission to read that key, why wouldn't an attacker just steal it too?

AFAIK, JCA provides a keystore mechanism, which I guess, provides enough means of protection against steal. I'm, however, too lazy to thoroughly read the JCA guide [1], but the first which comes to my mind is for example, external storage of keys.

[1]http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/Crypto...

Regards, Dimitar