Basic Auth

Hey Reddit, I am writing Auth into my server atm and I was hoping for some critiques or advice as well as answers to a few questions. Thanks :) Here is my approach. <h2></h2> REGISTRATION A. User sends <ul> <li>Email</li> <li>Username</li> <li>Hashed Password</li> </ul> B. Server checks that either the Email or Username doesn't already exist(whatever I decide is the human readable unique identifier). It then generates some Salt and adds that to the end of the Hashed Password. The server then hashes the two and creates the record <ul> <li>ID</li> <li>Email</li> <li>Username</li> <li>Hashed Password</li> <li>Salt</li> </ul> C. Server proceeds to perform the login function (but skips Auth in Login) <h2></h2> LOGIN A. User sends <ul> <li>Unique Identifier</li> <li>Hashed Password</li> </ul> B. Server takes the Unique Identifier and looks up the user in the database. If the user exists, it takes the users Salt and appends it to the Hashed Password. It hashes this and then checks this against the stored Password. If its a match, the server proceeds C. Server now generates a long series of random characters I will call the Session Token(proper name?), it then stores that in a database along with the users ID and any other information I would frequently lookup that is non-dynamic. D. The server then returns the Session Token to the client E. If the user requests to logout, destroy the row in the database <h2></h2> REQUESTS A. Whenever a user sends a request, it puts the Session Token in the Header B. The server reads the Session Token from the header and checks it against its Session Token database. This reliably proves who the user is <h2></h2> QUESTIONS: <ul> <li>1. During login, should I check to see if this user already exists in the Session Token table and return that Session Token</li> <li>2. Should I put a expiration date on the Session Tokens? If so how long do you suggest</li> <li>3. The length of the salt doesn't matter that much correct?</li> </ul> MORE QUESTIONS: <ul> <li>1. To speed up the operation I should put the Session Database into RAM somehow right? If so can you give me any advice on properly doing that.</li> </ul> <hr/>**评论：** elithrar_: <pre>I'm going to try and answer this as succinctly as possible: <h2>Registration</h2> <ol> <li>User sends email, username, password to your server (tip: just use the email address as the username if you can)</li> <li>Check for uniqueness</li> <li>Generate a password using Go's bcrypt lib <a href="https://godoc.org/golang.org/x/crypto/bcrypt">https://godoc.org/golang.org/x/crypto/bcrypt</a> or my scrypt lib <a href="https://github.com/elithrar/simple-scrypt">https://github.com/elithrar/simple-scrypt</a></li> <li>Create a session cookie using <a href="http://www.gorillatoolkit.org/pkg/sessions">http://www.gorillatoolkit.org/pkg/sessions</a> - storing the user ID (i.e. the UUID from the database) is good here. Provided the cookies are authenticated, and you're using a lib that checks, you can validate users on the presence of a <code>User</code> object or ID in the session cookie. Set a reasonable expiry based on your application - no longer than a week, IMO. Less is better.</li> </ol> <h2>Login</h2> <ol> <li>Accept email/password</li> <li>Look up user based on email, retrieving their password hash at the same time (usually you just retrieve your <code>User</code> object with those as fields)</li> <li>Use <code>bcrypt.CompareHashAndPassword</code> to compare their password from the POST form with the one you stored upon registration.</li> <li>Create a session cookie using <a href="http://www.gorillatoolkit.org/pkg/sessions">http://www.gorillatoolkit.org/pkg/sessions</a> - storing the user ID (i.e. the UUID from the database) is good here. Provided the cookies are authenticated, and you're using a lib that checks, you can validate users on the presence of a <code>User</code> object or ID in the session cookie. Set a reasonable expiry based on your application - no longer than a week, IMO. Less is better.</li> </ol> <h2>Requests</h2> <ol> <li>Write some middleware (see below for an outline) and wrap your routes or sub-router with it. e.g. <pre><code> func CheckAuth(h http.Handler) http.Handler { fn := func(w http.ResponseWriter, r *http.Request) { session, err := store.Get(r, "session_name") if err != nil { // Just a basic error page for this example http.Error(w, http.StatusText(http.InternalServerError), http.InternalServerError) return } // Check for a user object in session.Values // Re-direct to /login or throw a HTTP 403 if it doesn't exist // Check that (e.g.) user.ID is not empty // Call the next handler via h.ServeHTTP(w, r) // Else bounce them back to the login URL / throw a 403 again. } </code></pre></li> <li>Within this middleware, get the session, check if a non-nil <code>User</code> object is stored in there, check it hasn't expired (gorilla/sessions does a lot of this for you) and then call the next handler. Otherwise, re-direct to your <code>/login</code> route or call a <code>HTTP 403 Forbidden</code>(your preference).</li> </ol> <h3>Other notes:</h3> <ul> <li>Just use session cookies via <a href="http://www.gorillatoolkit.org/pkg/sessions">gorilla/sessions</a>. They are sent on every request (for which the path applies, to be precise) - they are already "in RAM" by the time your handlers are doing anything. You don't need to use a database as a session store for authentication. If you did, it still uses cookies to identify which database row holds the data.</li> <li>The length of the salt does matter, but if you use the <code>bcrypt</code> or <code>scrypt</code> libs I mentioned above, they handle that for you.</li> <li>See my other comments about expiration dates. Keep 'em as short as your users can manage. Write a <code>Logout</code> handler that sets the MaxAge field of the cookie in the past to "delete" the cookie for users who want to logout (the gorilla/sessions docs cover this)</li> </ul></pre>devsquid: <pre>Awesome. Thank you. I should mention this API is being used for a native app as well as a website. I am already using Gorilla for routing and I will look into sessions. So storing a session in RAM alone is completely fine? Maybe storing a receipt of it in the DB isn't a bad idea as well anyways. Not that it matters in my case, but would that solution be very scaleable? I guess if scaling was an issue you would have the server put the Session in a shared cache right?</pre>elithrar_: <pre>You don't store the session on the server - you store it in HTTP cookies. There's no need to store a ticket or receipt, as the cookie will be authenticated at a minimum (if you use gorilla/sessions correctly). This means that only your application can modify it correctly, so you can "trust" what the cookie contains. The <code>User{ID, Username, Email, PasswordHash}</code> is stored in the database upon registration and then consulted during login only. </pre>devsquid: <pre>Ok but the HTTP Cookie is stored in ram, right?</pre>elithrar_: <pre>Cookies are stored in the client (user) browser. Your server sets a <code>Set-Cookie</code> header with the cookie data encoded as a string. The client's browser sends that cookie back on every request via a <code>Cookie</code> header, which your application verifies (via HMAC; gorilla/sessions again!) and then inspects for the data you want (a user ID, for example). If you are thinking this is "slow" for some reason, it's not: the cookie contents end up in your web server's memory as part of the HTTP request. Cookies do impart a small overhead (up to 4KB, typically) on the data transferred but it's typically far less. Consulting a database is significantly slower. Cookies are effectively "stateless" - you don't need to save any information about the cookie on your side. The cookie itself stores that data. </pre>devsquid: <pre>Huh interesting. Thanks for pointing me in this direction. This is a much better solution, than my Tokens in RAM idea.</pre>devsquid: <pre>No i wasn't thinking it was slow, I was thinking my original idea was slow.... lol</pre>devsquid: <pre>Awesome man, implementation of Gorilla's Cookie library was eassssy af</pre>devsquid: <pre>So would storing a session in just a Map or a standard Array be advisable?</pre>: <pre>[deleted]</pre>devsquid: <pre>Why? I shouldn't add salt before hashing?</pre>: <pre>[deleted]</pre>devsquid: <pre>Huh I still don't get how does a Salt not protect a database. It means that someone ever got your database, they would have to decrypt each of the users passwords individually. You couldn't use a single lookup table across the entire database.</pre>anacrolix: <pre>Use bcrypt.</pre>devsquid: <pre>Yes I get the benefit of Hashing that can't be as optimized. But you are saying I shouldn't use Salt and I am curious why you think that.</pre>teepark: <pre>bcrypt includes a salt automatically. it's a widely cryptographer-approved complete password management package, that's the reason for the cargo-cultish chant.</pre>devsquid: <pre>Cool how does it include a salt automatically? How does it reliably get the Salt?</pre>teepark: <pre>the hash it spits out has the salt as a prefix. when generating a hash it also recognizes when you use a bcrypt-generated hash as the salt and just pulls the prefix. thus checking a password is actually just generating a hash of the plaintext password using the hash you're checking against as the salt, and seeing if you get the same thing out. the go package wraps this up in a reasonable api (also with a constant-time compare at the end) though; I only know this because I've done it in python. this is also compatible with the variable work factor, because it actually encodes the work factor into the salt.</pre>devsquid: <pre>Ok so it stores the salt with the hashed password. Cool thank you for answering my question and now just repeating dogma :)</pre>nindalf: <pre>Check out these two articles by Matasano Security on which password scheme you should use - <a href="http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes.html" rel="nofollow">from 2007</a> and from earlier <a href="http://chargen.matasano.com/chargen/2015/3/26/enough-with-the-salts-updates-on-secure-password-schemes.html" rel="nofollow">this year</a>. Both are excellent articles and I feel that all developers should listen to what they say.</pre>devsquid: <pre>Its also not like SHA256 is insecure in anyway, its just a easily optimized. A Salted and hashed password would still take forever to decrypt. But I will use bcrypt</pre>elithrar_: <pre><blockquote> Its also not like SHA256 is insecure in anyway, its just a easily optimized </blockquote> Brute forcing SHA-256 (a hash function) vs bcrypt, scrypt or PBKDF2 with the appropriate work factor (all of which are key derivation functions) is a MAGNITUDE of order faster. The SHA family is not designed for long-term key storage. As a shameless plug: <a href="https://github.com/elithrar/simple-scrypt" rel="nofollow">https://github.com/elithrar/simple-scrypt</a> else use <a href="https://godoc.org/golang.org/x/crypto/bcrypt" rel="nofollow">https://godoc.org/golang.org/x/crypto/bcrypt</a></pre>devsquid: <pre>Yes, i get its a huge order of magnitude more of work and can not be as easily hardware optimized.</pre>hahainternet: <pre>What you don't understand is that a simple salt is trivially defeated. Smart mechanisms like crypt add the salt to the password and then repeatedly hash many hundreds of times using this salt. This way a brute force has to redo each hash with the discovered salt for each potential key and each potential passphrase. Bcrypt uses a similar approach but with a configurable amount of re-hashing which allows you to make it hard in terms of CPU time. If you need to learn more about this, PM me or ask nicely in one of the security subreddits.</pre>devsquid: <pre>I did ask nicely but the only answer i got was use bcrypt which is good advice but was in no way an answer to the question. Also by trivial you mean very expensive and several decades for a single password.</pre>hahainternet: <pre><blockquote> Also by trivial you mean very expensive and several decades for a single password. </blockquote> Nope. Few GPUs and a salt and hash is easily defeated.</pre>devsquid: <pre>Really even when properly salted hash with like sha512? But even bcrypt salts the input, the issue isn't salting it's weak algorithms.</pre>gogolang: <pre>I wish there were an open-source Go library for user auth that included registration, password resets via e-mail, and all the hashing and session tokens. Getting security right is tricky and I'm betting that most people who are doing it on their own are going to get some part of it wrong. Perhaps yours could be that library. Your approach looks reasonable, but it also kind of depends how much security you want. First, I would not delete the session tokens on logout. Instead, I would keep the session tokens in the database and just flag that this session is logged out. I would also store the IP address alongside each session token generated. That way, you can give the user a way to examine past logins to search for any suspicious activity in their login history. Expiring your session tokens is really dependent on the application. If it's a banking application, it should be something like 30 minutes to an hour with a heartbeat that resets the clock when there's user activity. The salt should be long too. If your database is compromised and an attacker wants to uncover the password of a single individual, having a short salt will make it easier to uncover the password especially if the password is weak. </pre>klaaax: <pre>You could have that,but then some idiot would write a blog post about "why you shouldn't use library X" and shame the maintainer publicly.</pre>devsquid: <pre>So true, but you gotta just let the angry bloggers blog.</pre>gogolang: <pre>It's ok. We're all Go developers here. If you've spent any time on Quora you'll read a ton of Go bashing from the very vocal minority of Haskell programmers about why you shouldn't use Go and instead use Haskell. </pre>elithrar_: <pre><blockquote> I wish there were an open-source Go library for user auth that included registration, password resets via e-mail, and all the hashing and session tokens. Getting security right is tricky and I'm betting that most people who are doing it on their own are going to get some part of it wrong. Perhaps yours could be that library. </blockquote> The hard part is that doing so requires the library author to make a ton of assumptions about the underlying application. It's "easy" to write a lib like that for (say) Rails, Django, Flask because you can assume a lot of abstraction. ActiveRecord, for example. Go, on the other hand, is a language (and not a framework!) and users typically prefer to glue smaller libraries together instead of using 'kitchen sink' frameworks. Writing a complete authentication library with registration logic, user privs, password resets, etc means you need to either force an ORM onto your package users or tie yourself to a specific datastore (i.e. Postgres) because you need to store a lot of that data (users, password hashes, reset links) somewhere. I'm not saying it's impossible, but it's certainly a lot of work to abstract an authentication system to that extent, and you'd end up serving a very specific niche.</pre>devsquid: <pre>Thats a good point. I imagine once the ecosystem and the language matures, something will arise. But I still want to make my own right now anyways. I am not doing this for a client, its just for myself.</pre>: <pre>[deleted]</pre>deiwin: <pre>This <a href="https://github.com/go-authboss/authboss">https://github.com/go-authboss/authboss</a> ?</pre>devsquid: <pre>It doesn't seem that hard to do correctly. I like tracking the sessions rather then deleting them.</pre>devsquid: <pre>Why does the length of the salt matter, if its sufficiently long such that there are no repeats?</pre>boxtown: <pre>Hashing on the client side doesn't really add anything. You should be using HTTPS for any request containing information like passwords which obviates the need for obfuscation by hashing. Expiration dates are definitely a good idea but the amount of time is up to you. You have to balance between being safe but not annoying (e.g. a 20 min TTL) Again, its up to you but I would probably generate a new token per login request. If you use the same token, then a user logging out will log him out of any session he may have open</pre>devsquid: <pre>I figured hashing on the client side, incase there was any form of MITM attack.</pre>teepark: <pre>client-side hashing is a false security. not directly harmful, but not that helpful either. the indirect harm would be if you thought that because you're doing client-side hashing, you don't have to force HTTPS-only with a valid signed cert on (at least) your registration endpoint. that's the real way to protect against MITM scenarios.</pre>elithrar_: <pre><blockquote> I figured hashing on the client side, incase there was any form of MITM attack. </blockquote> If you use TLS (HTTPS) this isn't a real problem. If you don't, and you enact client-side hashing, you're still sending the JavaScript that does the hashing over the insecure channel. Someone could trivially MitM your JavaScript hash function, and then MitM the cleartext password over the wire anyway. Zero gains. If they can MitM your connection, MitM'ing your JavaScript is trivial by that point.</pre>boxtown: <pre>If you're using HTTPS, then there's really no worry of a MITM attack. If you're not, then hashing won't really help you either because the MITM could just capture the hashed password and it wouldn't be any different than him capturing the unhashed password.</pre>koffiezet: <pre>Personally, I dislike passwords, and prefer something like this: <ul> <li>user enters email <ul> <li>if user doesn't exist: create new</li> </ul></li> <li>generate random string, and insert in DB</li> <li>send user an email containing a login link containing the random string</li> </ul> The user then clicks the link: <ul> <li>You validate the email address + random string combination</li> <li>store login in session in cookie</li> </ul> Done.</pre>devsquid: <pre>That sorta works like Steve Gibson's sqrl technique. But still I don't think that method provides a good ux. It would seem like it would be better to just use oauth at that point. Thanks for your input though</pre>bmo111: <pre>Take a look at this. It has the basic use of bcrypt with user authentication. <a href="https://github.com/vegax87/Negroni-Boilerplate" rel="nofollow">https://github.com/vegax87/Negroni-Boilerplate</a> Feel free to ping me if you have any questions. I wrote something similar but sends a one time use token for registration to the user's email for them to click on. Once they have clicked that link, they can proceed to use the system as a user. This is to avoid bots from signing up.</pre>ikofai: <pre>Hello! As mentioned elsewhere in this thread there is: <a href="https://github.com/go-authboss/authboss" rel="nofollow">https://github.com/go-authboss/authboss</a> - It has a pretty comprehensive usage guide in the readme. I'm actually one of the owners of project and I suggest you check it out as it achieves what you're trying to do and more. Even if you don't use it, it may be a good learning source for you to reference. Additionally, we have a sample blog that utilizes it (as well as gorilla mux, gorilla session, etc): <a href="https://github.com/go-authboss/authboss-sample" rel="nofollow">https://github.com/go-authboss/authboss-sample</a> Feel free to PM me, post an issue on Github, or talk to us on Gitter: <a href="https://gitter.im/go-authboss/authboss" rel="nofollow">https://gitter.im/go-authboss/authboss</a> We're continually adding features as our spare time allows and are always looking for feedback.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题