Quantcast

web authentication

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

web authentication

Joe Armstrong-2
Slightly off topic. But I want to make an erlang web site.

1) How does web authentication work?

Let's assume something like:

   http://en.wikipedia.org/wiki/Digest_access_authentication

This is easy to understand.

What I don't understand is what happens if the session socket is closed.
Handshaking tales place over an open socket and the client is
authenticated - this
is easy to understand.

What happens if the socket is closed, and reopened in a subsequent request?
Does the server set and receive a session cookie? Does the client remember and
replay the authentication protocol?

How does this work?

2) I want to make a web thing that requires the user to authenticate themself.

Should I:

    a) Roll my own (some MD5 + cookies should do the job)
    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
    c) Something else?

Seems like for a real web site there is a lot of cruft involved
preventing spammers,
false-accounts, forgotten-passwords etc. can I get all of this for
free by getting
authentication credentials via goole/facebook or something? Is this
what OpenID does?

Finally is this entire authentication-user management-forgot my
password built-in
to any of the popular erlang web servers?

Cheers

/Joe
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Max Lapshin-2
I don't advise you to use HTTP-based authorization. It is very
unconvenient to do "logout" with it.
Cookie based is more flexible to use and easier maintained.

HTTP Header authorization and cookie authorization has nothing to do
with connection and sockets,
they are only per-request credentials. You should never believe that
next request on the same socket is from the same client,
because it may be HTTP proxy, that speaks with you.



On Thu, Jul 7, 2011 at 11:29 PM, Joe Armstrong <[hidden email]> wrote:
> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>

So, there are basically two type of plain-text authorizations: using
Auth: header and Cookie: header.

Auth: header with 401 response will make your browser raise popup with
login/password and Cookie: header is just a cookie.
You may use it as you wish and for example put unique number of session.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Tristan Sloughter
My suggestion to simplify a lot of this: use HTTPS. 

And I agree with Max to not use HTTP-based authorization.

I've implemented this along with password reset multiple times for Webmachine webapps... But I haven't yet separated it out for publishing to github. I hope to do this one day soon!

Other frameworks that provide pieces (or all) of what you need are Nitrogen, ChicagoBoss and Zotonic.

Tristan

On Thu, Jul 7, 2011 at 2:35 PM, Max Lapshin <[hidden email]> wrote:
I don't advise you to use HTTP-based authorization. It is very
unconvenient to do "logout" with it.
Cookie based is more flexible to use and easier maintained.

HTTP Header authorization and cookie authorization has nothing to do
with connection and sockets,
they are only per-request credentials. You should never believe that
next request on the same socket is from the same client,
because it may be HTTP proxy, that speaks with you.



On Thu, Jul 7, 2011 at 11:29 PM, Joe Armstrong <[hidden email]> wrote:
> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>

So, there are basically two type of plain-text authorizations: using
Auth: header and Cookie: header.

Auth: header with 401 response will make your browser raise popup with
login/password and Cookie: header is just a cookie.
You may use it as you wish and for example put unique number of session.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Mihai Balea
In reply to this post by Joe Armstrong-2

On Jul 7, 2011, at 3:29 PM, Joe Armstrong wrote:


> What happens if the socket is closed, and reopened in a subsequent request?
> Does the server set and receive a session cookie? Does the client remember and
> replay the authentication protocol?

If my understanding of things is correct, the client can use subsequent authenticated requests, by reusing the server supplied nonce, but issuing a different cnonce for each request. This can happen over one  persistent http connection or many discrete connections. The server supplied nonce will expire after a time, and the auth protocol will have to be replayed.

Mihai
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Frédéric Trottier-Hébert
In reply to this post by Joe Armstrong-2
The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.

I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)

If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.

======
A QUICK GUIDE TO SAFER WEB AUTHENTICATION
======
Modern authentication schemes usually work a bit that way
----------

i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)

ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.

iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.

iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.

v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.

That being said, the actual steps of authentication then become:

1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
2. The user enters his own password, submits it
3. The server hashes it through the same hashing function used when first saving the password
4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
4.a if they're different, the authentication failed
4.b if they're the same, go to 5.
5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.

When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.

Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.

---
Further considerations:

A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.

B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.

This means we need an external value, not coming from HTTP headers to make sure the request is good.

In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.

The safe way to do requires a few elements:

1. Never do changes with GET requests. GET is idempotent and free of side effects

2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.

3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.

The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.

4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.

C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.

========

That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.

--
Fred Hébert
http://www.erlang-solutions.com



On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:

> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>
>   http://en.wikipedia.org/wiki/Digest_access_authentication
>
> This is easy to understand.
>
> What I don't understand is what happens if the session socket is closed.
> Handshaking tales place over an open socket and the client is
> authenticated - this
> is easy to understand.
>
> What happens if the socket is closed, and reopened in a subsequent request?
> Does the server set and receive a session cookie? Does the client remember and
> replay the authentication protocol?
>
> How does this work?
>
> 2) I want to make a web thing that requires the user to authenticate themself.
>
> Should I:
>
>    a) Roll my own (some MD5 + cookies should do the job)
>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>    c) Something else?
>
> Seems like for a real web site there is a lot of cruft involved
> preventing spammers,
> false-accounts, forgotten-passwords etc. can I get all of this for
> free by getting
> authentication credentials via goole/facebook or something? Is this
> what OpenID does?
>
> Finally is this entire authentication-user management-forgot my
> password built-in
> to any of the popular erlang web servers?
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Tristan Sloughter
Really (in my opinion) everything should be in https, not just the login page, if you want to ensure that a users session is not stolen. Session stealing is very simple. A click of a button for a script kiddie on the same wireless network in the coffee shop with you. But the argument against that is "speed". I think the overhead https causes compared to the benefits and Internets speeds today make using https the way to go now.

Tristan

2011/7/7 Frédéric Trottier-Hébert <[hidden email]>
The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.

I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)

If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.

======
A QUICK GUIDE TO SAFER WEB AUTHENTICATION
======
Modern authentication schemes usually work a bit that way
----------

i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)

ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.

iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.

iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.

v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.

That being said, the actual steps of authentication then become:

1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
2. The user enters his own password, submits it
3. The server hashes it through the same hashing function used when first saving the password
4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
4.a if they're different, the authentication failed
4.b if they're the same, go to 5.
5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.

When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.

Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.

---
Further considerations:

A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.

B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.

This means we need an external value, not coming from HTTP headers to make sure the request is good.

In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.

The safe way to do requires a few elements:

1. Never do changes with GET requests. GET is idempotent and free of side effects

2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.

3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.

The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.

4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.

C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.

========

That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.

--
Fred Hébert
http://www.erlang-solutions.com



On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:

> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>
>   http://en.wikipedia.org/wiki/Digest_access_authentication
>
> This is easy to understand.
>
> What I don't understand is what happens if the session socket is closed.
> Handshaking tales place over an open socket and the client is
> authenticated - this
> is easy to understand.
>
> What happens if the socket is closed, and reopened in a subsequent request?
> Does the server set and receive a session cookie? Does the client remember and
> replay the authentication protocol?
>
> How does this work?
>
> 2) I want to make a web thing that requires the user to authenticate themself.
>
> Should I:
>
>    a) Roll my own (some MD5 + cookies should do the job)
>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>    c) Something else?
>
> Seems like for a real web site there is a lot of cruft involved
> preventing spammers,
> false-accounts, forgotten-passwords etc. can I get all of this for
> free by getting
> authentication credentials via goole/facebook or something? Is this
> what OpenID does?
>
> Finally is this entire authentication-user management-forgot my
> password built-in
> to any of the popular erlang web servers?
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Frédéric Trottier-Hébert
True, but HTTPS has performance impacts that sometimes people find unacceptable. If you read down the guide you'll see that I do mention HTTPS by default, but a strict minimum should be the login page. You want to protect the user password more than the user's data on your site, for the simple reason that the password can be used in other places and the very risky operations should always ask for a password. 

HTTPS everywhere is the safest way to communicate with the server, yes.

On 2011-07-07, at 16:08 PM, Tristan Sloughter wrote:

Really (in my opinion) everything should be in https, not just the login page, if you want to ensure that a users session is not stolen. Session stealing is very simple. A click of a button for a script kiddie on the same wireless network in the coffee shop with you. But the argument against that is "speed". I think the overhead https causes compared to the benefits and Internets speeds today make using https the way to go now.

Tristan

2011/7/7 Frédéric Trottier-Hébert <[hidden email]>
The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.

I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)

If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.

======
A QUICK GUIDE TO SAFER WEB AUTHENTICATION
======
Modern authentication schemes usually work a bit that way
----------

i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)

ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.

iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.

iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.

v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.

That being said, the actual steps of authentication then become:

1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
2. The user enters his own password, submits it
3. The server hashes it through the same hashing function used when first saving the password
4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
4.a if they're different, the authentication failed
4.b if they're the same, go to 5.
5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.

When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.

Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.

---
Further considerations:

A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.

B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.

This means we need an external value, not coming from HTTP headers to make sure the request is good.

In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.

The safe way to do requires a few elements:

1. Never do changes with GET requests. GET is idempotent and free of side effects

2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.

3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.

The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.

4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.

C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.

========

That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.

--
Fred Hébert
http://www.erlang-solutions.com



On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:

> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>
>   http://en.wikipedia.org/wiki/Digest_access_authentication
>
> This is easy to understand.
>
> What I don't understand is what happens if the session socket is closed.
> Handshaking tales place over an open socket and the client is
> authenticated - this
> is easy to understand.
>
> What happens if the socket is closed, and reopened in a subsequent request?
> Does the server set and receive a session cookie? Does the client remember and
> replay the authentication protocol?
>
> How does this work?
>
> 2) I want to make a web thing that requires the user to authenticate themself.
>
> Should I:
>
>    a) Roll my own (some MD5 + cookies should do the job)
>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>    c) Something else?
>
> Seems like for a real web site there is a lot of cruft involved
> preventing spammers,
> false-accounts, forgotten-passwords etc. can I get all of this for
> free by getting
> authentication credentials via goole/facebook or something? Is this
> what OpenID does?
>
> Finally is this entire authentication-user management-forgot my
> password built-in
> to any of the popular erlang web servers?
>
> Cheers
>
> /Joe
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Banibrata Dutta
In reply to this post by Frédéric Trottier-Hébert
Thanks for the amazing, simple-worded, web-authentication run down.

All the other comments so far as as great. Gets my "thread of the month" award ("movie of the month" award IMHO, goes to the Erlang web-server perf comparison movie).

Am willing to spend some money on buying a mini e/Book (Wikibooks?) or the likes if this kind of info is turned into a "Learn You Some Web-Authentication"... or slightly broader "Learn You Some Practical & Professional Web-Development" :-). And if it uses Erlang as the lang of choice for examples, all the more better. [subtle hint ;-)]

2011/7/8 Frédéric Trottier-Hébert <[hidden email]>
The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.

I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)

If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.

======
A QUICK GUIDE TO SAFER WEB AUTHENTICATION
======
Modern authentication schemes usually work a bit that way
----------

i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)

ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.

iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.

iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.

v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.

That being said, the actual steps of authentication then become:

1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
2. The user enters his own password, submits it
3. The server hashes it through the same hashing function used when first saving the password
4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
4.a if they're different, the authentication failed
4.b if they're the same, go to 5.
5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.

When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.

Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.

---
Further considerations:

A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.

B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.

This means we need an external value, not coming from HTTP headers to make sure the request is good.

In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.

The safe way to do requires a few elements:

1. Never do changes with GET requests. GET is idempotent and free of side effects

2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.

3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.

The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.

4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.

C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.

========

That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.

--
Fred Hébert
http://www.erlang-solutions.com



On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:

> Slightly off topic. But I want to make an erlang web site.
>
> 1) How does web authentication work?
>
> Let's assume something like:
>
>   http://en.wikipedia.org/wiki/Digest_access_authentication
>
> This is easy to understand.
>
> What I don't understand is what happens if the session socket is closed.
> Handshaking tales place over an open socket and the client is
> authenticated - this
> is easy to understand.
>
> What happens if the socket is closed, and reopened in a subsequent request?
> Does the server set and receive a session cookie? Does the client remember and
> replay the authentication protocol?
>
> How does this work?
>
> 2) I want to make a web thing that requires the user to authenticate themself.
>
> Should I:
>
>    a) Roll my own (some MD5 + cookies should do the job)
>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>    c) Something else?
>
> Seems like for a real web site there is a lot of cruft involved
> preventing spammers,
> false-accounts, forgotten-passwords etc. can I get all of this for
> free by getting
> authentication credentials via goole/facebook or something? Is this
> what OpenID does?
>
> Finally is this entire authentication-user management-forgot my
> password built-in
> to any of the popular erlang web servers?
>
> Cheers
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Joe Armstrong-2
In reply to this post by Frédéric Trottier-Hébert
2011/7/7 Frédéric Trottier-Hébert <[hidden email]>:

> The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.
>
> I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)
>
> If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.
>
> ======
> A QUICK GUIDE TO SAFER WEB AUTHENTICATION
> ======
> Modern authentication schemes usually work a bit that way
> ----------
>
> i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)
>
> ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.
>
> iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.
>
> iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.
>
> v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.
>
> That being said, the actual steps of authentication then become:
>
> 1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
> 2. The user enters his own password, submits it
> 3. The server hashes it through the same hashing function used when first saving the password
> 4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
> 4.a if they're different, the authentication failed
> 4.b if they're the same, go to 5.
> 5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
> 6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.
>
> When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.
>
> Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.
>
> ---
> Further considerations:
>
> A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.
>
> B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.
>
> This means we need an external value, not coming from HTTP headers to make sure the request is good.
>
> In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.
>
> The safe way to do requires a few elements:
>
> 1. Never do changes with GET requests. GET is idempotent and free of side effects
>
> 2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.
>
> 3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.
>
> The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.
>
> 4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.
>
> C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.

Thank you - that was very helpful.

Actually I have implement RSA
and a few other things in pure Erlang using bignums - one property
of these is that they are slow - (which is desirable by point iii) above
I'd never thought that slowness could be an advantage.

/Joe

>
> ========
>
> That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.
>
> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>
>
> On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:
>
>> Slightly off topic. But I want to make an erlang web site.
>>
>> 1) How does web authentication work?
>>
>> Let's assume something like:
>>
>>   http://en.wikipedia.org/wiki/Digest_access_authentication
>>
>> This is easy to understand.
>>
>> What I don't understand is what happens if the session socket is closed.
>> Handshaking tales place over an open socket and the client is
>> authenticated - this
>> is easy to understand.
>>
>> What happens if the socket is closed, and reopened in a subsequent request?
>> Does the server set and receive a session cookie? Does the client remember and
>> replay the authentication protocol?
>>
>> How does this work?
>>
>> 2) I want to make a web thing that requires the user to authenticate themself.
>>
>> Should I:
>>
>>    a) Roll my own (some MD5 + cookies should do the job)
>>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>>    c) Something else?
>>
>> Seems like for a real web site there is a lot of cruft involved
>> preventing spammers,
>> false-accounts, forgotten-passwords etc. can I get all of this for
>> free by getting
>> authentication credentials via goole/facebook or something? Is this
>> what OpenID does?
>>
>> Finally is this entire authentication-user management-forgot my
>> password built-in
>> to any of the popular erlang web servers?
>>
>> Cheers
>>
>> /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Frédéric Trottier-Hébert
Slowness is only helpful when it is slow across all languages, though. If your RSA is slow in Erlang, but very fast in C, Fortran or whatever language, then it doesn't matter. Someone who finds your database (lost backup, infiltrating your servers, SQL injection, etc) will use the language they want to run these algorithms. Again, that's why bcrypt and scrypt are so useful as hash functions. The work factor you give them makes it sure that *any* implementation is going to take a lot of time to do its thing.

But yeah, that algorithmic slowness is warranted is a funny thing.

--
Fred Hébert
http://www.erlang-solutions.com



On 2011-07-08, at 05:57 AM, Joe Armstrong wrote:

> 2011/7/7 Frédéric Trottier-Hébert <[hidden email]>:
>> The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.
>>
>> I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)
>>
>> If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.
>>
>> ======
>> A QUICK GUIDE TO SAFER WEB AUTHENTICATION
>> ======
>> Modern authentication schemes usually work a bit that way
>> ----------
>>
>> i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)
>>
>> ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.
>>
>> iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.
>>
>> iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.
>>
>> v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.
>>
>> That being said, the actual steps of authentication then become:
>>
>> 1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
>> 2. The user enters his own password, submits it
>> 3. The server hashes it through the same hashing function used when first saving the password
>> 4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
>> 4.a if they're different, the authentication failed
>> 4.b if they're the same, go to 5.
>> 5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
>> 6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.
>>
>> When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.
>>
>> Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.
>>
>> ---
>> Further considerations:
>>
>> A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.
>>
>> B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.
>>
>> This means we need an external value, not coming from HTTP headers to make sure the request is good.
>>
>> In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.
>>
>> The safe way to do requires a few elements:
>>
>> 1. Never do changes with GET requests. GET is idempotent and free of side effects
>>
>> 2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.
>>
>> 3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.
>>
>> The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.
>>
>> 4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.
>>
>> C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.
>
> Thank you - that was very helpful.
>
> Actually I have implement RSA
> and a few other things in pure Erlang using bignums - one property
> of these is that they are slow - (which is desirable by point iii) above
> I'd never thought that slowness could be an advantage.
>
> /Joe
>
>>
>> ========
>>
>> That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.
>>
>> --
>> Fred Hébert
>> http://www.erlang-solutions.com
>>
>>
>>
>> On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:
>>
>>> Slightly off topic. But I want to make an erlang web site.
>>>
>>> 1) How does web authentication work?
>>>
>>> Let's assume something like:
>>>
>>>   http://en.wikipedia.org/wiki/Digest_access_authentication
>>>
>>> This is easy to understand.
>>>
>>> What I don't understand is what happens if the session socket is closed.
>>> Handshaking tales place over an open socket and the client is
>>> authenticated - this
>>> is easy to understand.
>>>
>>> What happens if the socket is closed, and reopened in a subsequent request?
>>> Does the server set and receive a session cookie? Does the client remember and
>>> replay the authentication protocol?
>>>
>>> How does this work?
>>>
>>> 2) I want to make a web thing that requires the user to authenticate themself.
>>>
>>> Should I:
>>>
>>>    a) Roll my own (some MD5 + cookies should do the job)
>>>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>>>    c) Something else?
>>>
>>> Seems like for a real web site there is a lot of cruft involved
>>> preventing spammers,
>>> false-accounts, forgotten-passwords etc. can I get all of this for
>>> free by getting
>>> authentication credentials via goole/facebook or something? Is this
>>> what OpenID does?
>>>
>>> Finally is this entire authentication-user management-forgot my
>>> password built-in
>>> to any of the popular erlang web servers?
>>>
>>> Cheers
>>>
>>> /Joe
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Joe Armstrong-2
2011/7/8 Frédéric Trottier-Hébert <[hidden email]>:
> Slowness is only helpful when it is slow across all languages, though. If your RSA is slow in Erlang, but very fast in C, Fortran or whatever language, then it doesn't matter. Someone who finds your database (lost backup, infiltrating your servers, SQL injection, etc) will use the language they want to run these algorithms. Again, that's why bcrypt and scrypt are so useful as hash functions. The work factor you give them makes it sure that *any* implementation is going to take a lot of time to do its thing.

Point taken - though there is no C code (yet) to decode my RSA certificates
(which are just term_to_binary({A,B,C}) where A B and C are bignums
for computing A^B mod(C) :-)

> But yeah, that algorithmic slowness is warranted is a funny thing.
>
> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>
>
> On 2011-07-08, at 05:57 AM, Joe Armstrong wrote:
>
>> 2011/7/7 Frédéric Trottier-Hébert <[hidden email]>:
>>> The digest authentication you see at this point is something that's part of the HTTP protocol. It is technically unrelated to your application (although your application can see it through HTTP values) and the client-side of it is implemented by the browser.
>>>
>>> I would consider it highly impractical for how little control it gives you (even in terms of visual design) and in general security. The browser being in charge of it means the session handling is annoying (no way to disconnect, the browser just resubmits the data all the time for you, proxies become tedious, etc.)
>>>
>>> If you're okay for a longer read, here's what I know, in condensed format. Others can feel free to correct me.
>>>
>>> ======
>>> A QUICK GUIDE TO SAFER WEB AUTHENTICATION
>>> ======
>>> Modern authentication schemes usually work a bit that way
>>> ----------
>>>
>>> i. The user registers to the website on an HTTPS page (so that the password being sent isn't observable by third parties)
>>>
>>> ii. The password is stored in a database after being hashed by bcrypt or scrypt with a convenient, but slow work factor as to make brute-force (if the DB is compromised) absolutely impractical. These algorithms store their own difficulty factor, so that if you want to up the complexity, it can be done quite simply even if you have many versions in the DB.
>>>
>>> iii. Avoid using MD5 or SHA-x hashing functions. MD5 is collision-prone, some of the SHA functions too. MD5 and SHA hashing functions were made to be really fast and we want to avoid that. The reason is that it makes it easier to brute-force passwords if the table is compromised. Protect your users first. Bcrypt and Scrypt, by comparison, will salt the passwords for you and give each of them a work factor. If you take 100 millisecond to check a password (something that happens once per session, so it's fine to be slow) compared to 10 microseconds, it becomes a real pain for crackers to do their thing. During that time, you can warn your users to change their passwords in other services.
>>>
>>> iv. bcrypt and scrypt handle salting for you, as mentioned before. If you decided not to use them, do remember to salt your passwords to avoid easier rainbow table attacks. Do NOT reapply a hash function many times over a previous hash results. Because all hash functions have collisions, this means that as you go, you increase the chances of collisions. Re-salt at each iteration. Again, if you use bcrypt or scrypt, this is handled for you and you do not have to worry. Please use bcrypt or scrypt.
>>>
>>> v. If that wasn't obvious, use the hashing function of bcrypt, not the encryption that can be decrypted. You do NOT want to use encryption, but hashing. The reason is simple. If your system is compromised, you have to assume that your keys are also compromised. Encryption is unsafe for passwords. Hashing is the king.
>>>
>>> That being said, the actual steps of authentication then become:
>>>
>>> 1. The login page is an HTTPS page so that the password that will be sent isn't observable by third parties
>>> 2. The user enters his own password, submits it
>>> 3. The server hashes it through the same hashing function used when first saving the password
>>> 4. Compare the two hash values. Note: you want this to be done in O(n) time so that it's impossible to know whether you get partial matches or not. This makes more sense for clear text passwords, but what the hell.
>>> 4.a if they're different, the authentication failed
>>> 4.b if they're the same, go to 5.
>>> 5. Create some kind of session value in another table or wherever you want. The session will have a key that you can choose randomly (UUIDv4 + userid to avoid duplicates although the chances are minimal, as an example).
>>> 6. Put the value in a cookie. You want that cookie to be set with the option HttpOnly to avoid having client-side javascript able to read it. Also give a reasonable timeout value to the cookie so the user has to re-authenticate from time to time. This means both server-time timeouts and client-side timeouts.
>>>
>>> When a user loads a page, check the session cookie you defined, and match its value to whatever you've got in your session table. If it matches, the user has an active session. If it doesn't, have the user authenticate again.
>>>
>>> Note that this scheme (and pretty much any other) is insecure against 3rd parties listening to the communications between you and the server. To solve this, move everything to HTTPS, although this is harder to optimise for performance.
>>>
>>> ---
>>> Further considerations:
>>>
>>> A. Put a limit on how many times someone can try to log in. You can have their account locked for a few minutes in between each time. This is to keep people from trying to brute force accounts from the outside.
>>>
>>> B. HTTP cookies alone are not sufficient to know whether someone is authenticated or not. A specific kind of attack, named Cross-Site Request Forgery (CSRF) works by having someone doing an HTTP request for you, from a different domain. In these cases, the browser will automatically send the cookies along with the request (it can also be a javascript form that's auto-submitted). I've used this in the past to have a site administrator (a co-worker) close his own account without him noticing it. Woops.
>>>
>>> This means we need an external value, not coming from HTTP headers to make sure the request is good.
>>>
>>> In simple cases, you can try to check the referrer and make sure it's coming from your domain. However, flash components or HTTPS connections do not always have these settings, and if you have any of these pages on your site (and you will, if you do HTTPS authentication), you'll have to look somewhere else.
>>>
>>> The safe way to do requires a few elements:
>>>
>>> 1. Never do changes with GET requests. GET is idempotent and free of side effects
>>>
>>> 2. Do your changes with POST. This will require a user to use either a) Javascript, b) curl, wget or some other tool or c) an HTML form to send your data. This restricts the window of opportunity of malevolent users, who can no longer just post a link or an image to do CSRF.
>>>
>>> 3. This is the most important point, use something called a token. This token is a special value that is added to whatever form you generate. When the user sends a POST query (or anything requiring server-side changes) to you, check that the token is there and that it is valid. The best tokens will have a one-time use, but they're fairly impractical when many different queries can be done without refreshing a page. My favourite way to handle these otherwise is to create different tokens for different namespaces. The admin panel will have its own token, the chat system its own token, the user settings will also have its own, etc.
>>>
>>> The tokens have to time out at some point to make sure that someone who steals them can not damage the account for too long. Pick between a few seconds to a few hours based on how long you expect your user to stay on a single page.
>>>
>>> 4. Ask for the user password when changing vital information, such as the e-mail attached to the account, the password itself, buying an item, etc.
>>>
>>> C. Never roll out your own encryption schemes or hash functions. Let mathematicians specialised in cryptography do their thing.
>>
>> Thank you - that was very helpful.
>>
>> Actually I have implement RSA
>> and a few other things in pure Erlang using bignums - one property
>> of these is that they are slow - (which is desirable by point iii) above
>> I'd never thought that slowness could be an advantage.
>>
>> /Joe
>>
>>>
>>> ========
>>>
>>> That should be about it for a quick guide. There are more complex issues to tackle for good authentication and security of user data, but as a basic intro, this should be okay. I hope this is helpful.
>>>
>>> --
>>> Fred Hébert
>>> http://www.erlang-solutions.com
>>>
>>>
>>>
>>> On 2011-07-07, at 15:29 PM, Joe Armstrong wrote:
>>>
>>>> Slightly off topic. But I want to make an erlang web site.
>>>>
>>>> 1) How does web authentication work?
>>>>
>>>> Let's assume something like:
>>>>
>>>>   http://en.wikipedia.org/wiki/Digest_access_authentication
>>>>
>>>> This is easy to understand.
>>>>
>>>> What I don't understand is what happens if the session socket is closed.
>>>> Handshaking tales place over an open socket and the client is
>>>> authenticated - this
>>>> is easy to understand.
>>>>
>>>> What happens if the socket is closed, and reopened in a subsequent request?
>>>> Does the server set and receive a session cookie? Does the client remember and
>>>> replay the authentication protocol?
>>>>
>>>> How does this work?
>>>>
>>>> 2) I want to make a web thing that requires the user to authenticate themself.
>>>>
>>>> Should I:
>>>>
>>>>    a) Roll my own (some MD5 + cookies should do the job)
>>>>    b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
>>>>    c) Something else?
>>>>
>>>> Seems like for a real web site there is a lot of cruft involved
>>>> preventing spammers,
>>>> false-accounts, forgotten-passwords etc. can I get all of this for
>>>> free by getting
>>>> authentication credentials via goole/facebook or something? Is this
>>>> what OpenID does?
>>>>
>>>> Finally is this entire authentication-user management-forgot my
>>>> password built-in
>>>> to any of the popular erlang web servers?
>>>>
>>>> Cheers
>>>>
>>>> /Joe
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> [hidden email]
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Joe Armstrong-2
In reply to this post by Joe Armstrong-2
2011/7/8 Jack Moffitt <[hidden email]>:

>> Actually I have implement RSA
>> and a few other things in pure Erlang using bignums - one property
>> of these is that they are slow - (which is desirable by point iii) above
>> I'd never thought that slowness could be an advantage.
>
> If you are interested in slowness being a feature, you should read the
> Bitcoin paper and the other related work on "forced work". It turns
> out to be a quite useful primitive for certain things. In Bitcoin for
> example, the forced work is also scalable, so the minting of new coins
> in the system happens at an approximately constant rate despite
> technology upgrades and the influx of new workers.
>
> jack.

Ummm - now wait a moment

I think I can prove that NP = P - Yes - Eureka

Unfortunately the margin isn't big enough ...

/Joe
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Jon Watte
In reply to this post by Joe Armstrong-2
You've already gotten some good answers; however, having worked extensively with this myself, I recommend:
 
1) Use HTTPS for all traffic. Computers are fast. Crypto is cheap. Cookie theft is a reality on open channels.
 
2) Use Basic-auth over HTTP -- this sends name and password, base-64-encoded.
 
3) HTTP is stateless. The auth will be sent with each and every request. The fact that HTTP/1.1 allows you to keep the physical TCP connection open and send another request is purely an optimization; you cannot assume anything about the next request that comes in. In fact, a HTTP gateway may multiplex multiple internal users to a single external connection, and send different credentials (including no credentials) with each request.
 
The stateless nature of HTTP is what makes it scale really, really well for certain problem domains and usage patterns. It's also what makes it a pain in the butt when certain kinds of efficiencies are important. This area is fraught with more distress than you would normally think. I believe this is because old-school networking people sometimes haven't yet realized the benefits of HTTP as currently implemented and optimized; meanwhile, web-only people often don't understand that there are cases where HTTP is NOT the right solution. Sitting in the middle is fun and frustrating at the same time ;-)
 
Sincerely,
 
jw


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Thu, Jul 7, 2011 at 12:29 PM, Joe Armstrong <[hidden email]> wrote:
Slightly off topic. But I want to make an erlang web site.

1) How does web authentication work?

Let's assume something like:

  http://en.wikipedia.org/wiki/Digest_access_authentication

This is easy to understand.

What I don't understand is what happens if the session socket is closed.
Handshaking tales place over an open socket and the client is
authenticated - this
is easy to understand.

What happens if the socket is closed, and reopened in a subsequent request?
Does the server set and receive a session cookie? Does the client remember and
replay the authentication protocol?

How does this work?

2) I want to make a web thing that requires the user to authenticate themself.

Should I:

   a) Roll my own (some MD5 + cookies should do the job)
   b) Implement  http://en.wikipedia.org/wiki/Digest_access_authentication
   c) Something else?

Seems like for a real web site there is a lot of cruft involved
preventing spammers,
false-accounts, forgotten-passwords etc. can I get all of this for
free by getting
authentication credentials via goole/facebook or something? Is this
what OpenID does?

Finally is this entire authentication-user management-forgot my
password built-in
to any of the popular erlang web servers?

Cheers

/Joe
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Max Lapshin-2
On Sat, Jul 9, 2011 at 9:20 AM, Jon Watte <[hidden email]> wrote:
> You've already gotten some good answers; however, having worked extensively
> with this myself, I recommend:
>
> 1) Use HTTPS for all traffic. Computers are fast. Crypto is cheap. Cookie
> theft is a reality on open channels.
>

This is not as clear as it seems to.
1) HTTPS add delay. It is not a blocking problem for social
network/wiki, but it is a profit penalty for online shop
2) HTTPS still has issues with Internet Explorer, when some code is
HTTP and some is HTTPS. And when something is HTTPS, but IE thinks it
is HTTP


> 2) Use Basic-auth over HTTP -- this sends name and password,
> base-64-encoded.
>

Sorry, but it is very, very bad recommendation. You are afraid of
cookie stealing and this is why you recommend to send name and
password
plaintext on each request. What for?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Jon Watte
You should not send name/password in clear text. You should send it using HTTP+TLS == HTTPS! My three suggestions should be used together.
The more salient point is that a REST client may or may not like cookies, because you cannot, for example, issue multiple requests in parallel until you've first done the stateful, cookie-generating, initial server round-trip.
 
HTTPS has had some performance problems with an additional round-trip during connection negotiation for TLS. For browsers that re-use the connection (all HTTP/1.1 browser), this is not much of a problem. However, our friends at Google have actually done a lot of research in how to front-load the necessary packets, so that you can recude the negotiation overhead to close to zero, without a change in protocol! It's quite fascinating. For an initial look, check out:
 
Sincerely,
 
jw
 


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Fri, Jul 8, 2011 at 10:40 PM, Max Lapshin <[hidden email]> wrote:
On Sat, Jul 9, 2011 at 9:20 AM, Jon Watte <[hidden email]> wrote:
> You've already gotten some good answers; however, having worked extensively
> with this myself, I recommend:
>
> 1) Use HTTPS for all traffic. Computers are fast. Crypto is cheap. Cookie
> theft is a reality on open channels.
>

This is not as clear as it seems to.
1) HTTPS add delay. It is not a blocking problem for social
network/wiki, but it is a profit penalty for online shop
2) HTTPS still has issues with Internet Explorer, when some code is
HTTP and some is HTTPS. And when something is HTTPS, but IE thinks it
is HTTP


> 2) Use Basic-auth over HTTP -- this sends name and password,
> base-64-encoded.
>

Sorry, but it is very, very bad recommendation. You are afraid of
cookie stealing and this is why you recommend to send name and
password
plaintext on each request. What for?


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Garrett Smith-5
In reply to this post by Jon Watte
On Fri, Jul 8, 2011 at 11:20 PM, Jon Watte <[hidden email]> wrote:

> 2) Use Basic-auth over HTTP -- this sends name and password,
> base-64-encoded.

This is surely a typo. You can't say "HTTP" and expect people to read
"HTTP + TLS".

For simple web auth, I routinely use basic auth, but only ever over
HTTPS. This doesn't work however if you need to control sessions or
let users log out. It's just a quick and dirty way to control who can
see what.

Garrett
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Jon Watte
My three suggestions were intended to be used together. The HTTP protocol is what defines Basic-Auth. The encapsulation into TLS is transparent to that particular step. My apologies if this confused my recommendation.

Logging out can be accomplished by simply sending an "unauthenticated" HTTP status code and a new Authenticate header that tells the client it needs new credentials.

HTTP authentication is superior to cookie-based authentication in a number of cases where the REST nature of the web allows for various kinds of mash-ups. Cookie-based authentication really only works well when an interactive user is using a mainline web browser to access your application. Kind-of like using the flash player for your website: some designers think nothing about it; others believe that it significantly reduces the value of the site, at least long-term. Let your requirements decide.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Mon, Jul 11, 2011 at 10:16 AM, Garrett Smith <[hidden email]> wrote:
On Fri, Jul 8, 2011 at 11:20 PM, Jon Watte <[hidden email]> wrote:

> 2) Use Basic-auth over HTTP -- this sends name and password,
> base-64-encoded.

This is surely a typo. You can't say "HTTP" and expect people to read
"HTTP + TLS".

For simple web auth, I routinely use basic auth, but only ever over
HTTPS. This doesn't work however if you need to control sessions or
let users log out. It's just a quick and dirty way to control who can
see what.

Garrett


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Tim Fletcher-6
> Logging out can be accomplished by simply sending an "unauthenticated" HTTP
> status code and a new Authenticate header that tells the client it needs new
> credentials.

Most browsers will cache HTTP Auth credentials until the end of the
browser session, so although it looks like you've logged out, you'll
often be able to get straight back in again without having to re-enter
a password. This usability issue is more significant a problem than
the overhead of SSL, IMO.

An alternative to storing session data on the server is to use signed/
encrypted cookies. Stefan Tilkov outlined a general approach for doing
this, which you can use in any language:

  http://www.innoq.com/blog/st/2009/06/devoxx_08_rest_patterns_and_an.html
(slide 44 of 71)

  - ask user for name and password if no cookie passed
  - authenticate user
  - create auth token as username + expiry date
  - hash(auth token + server secret)
  - return cookie as hash + auth_token
  - server validates with algorithm on in-memory data

Hope that helps.

Cheers,
Tim
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Joe Armstrong-2
I'm still following this thread with interest thanks for all the information.

It seems like there are two phases:

1) initial authentication
    Here there is some kind of challenge/response interaction
    If this succeeds the server sends a session cookie to the client.

2) Per-connection authentication.
    If 1) has succeeded, the client sends the session cookie to the
    in each new request. The sever uses this as a key into a database
    if the database lookup matches the correct user then everything is ok
    This has to be done ever time a new socket is opened.

My original question also asked about openId - can't I get google (or something)
to authenticate the user then do some kind of hand-over to me? If this
is the case then I wouldn't have to bother with the details of passwords myself

Cheers

/Joe








On Mon, Jul 18, 2011 at 6:22 PM, Tim Fletcher <[hidden email]> wrote:

>> Logging out can be accomplished by simply sending an "unauthenticated" HTTP
>> status code and a new Authenticate header that tells the client it needs new
>> credentials.
>
> Most browsers will cache HTTP Auth credentials until the end of the
> browser session, so although it looks like you've logged out, you'll
> often be able to get straight back in again without having to re-enter
> a password. This usability issue is more significant a problem than
> the overhead of SSL, IMO.
>
> An alternative to storing session data on the server is to use signed/
> encrypted cookies. Stefan Tilkov outlined a general approach for doing
> this, which you can use in any language:
>
>  http://www.innoq.com/blog/st/2009/06/devoxx_08_rest_patterns_and_an.html
> (slide 44 of 71)
>
>  - ask user for name and password if no cookie passed
>  - authenticate user
>  - create auth token as username + expiry date
>  - hash(auth token + server secret)
>  - return cookie as hash + auth_token
>  - server validates with algorithm on in-memory data
>
> Hope that helps.
>
> Cheers,
> Tim
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: web authentication

Wilson MacGyver
Yes, you can use either google or facebook as a login in place of your
own system.
You'd use oAuth for this. Basically it involves bouncing them to
either a google or
facebook login page, with a url to return to on success.

when it returns back, you'll have a token.

we use it for exporting data out of google. more info at

http://code.google.com/apis/gdata/articles/oauth.html

in that article, there is also a link to google's oauth playground for
testing and see how it works.

the facebook one is documented at
http://developers.facebook.com/docs/authentication/

Twitter also provides very similar service too.

On Mon, Jul 18, 2011 at 3:13 PM, Joe Armstrong <[hidden email]> wrote:
> My original question also asked about openId - can't I get google (or something)
> to authenticate the user then do some kind of hand-over to me? If this
> is the case then I wouldn't have to bother with the details of passwords myself

--
Omnem crede diem tibi diluxisse supremum.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12
Loading...