4 ms·

The security section, specifically on encryption, is dangerously misleading. It really needs an overhaul. To start with - DES is broken, you cannot use it. It

by tbiehn 11y ago

The security section, specifically on encryption, is dangerously misleading. It really needs an overhaul. To start with - DES is broken, you cannot use it. It also totally blasts over important details like -not re-using the same IV- for AES. Really, it should be updated to use a better higher-level general purpose encrypt/decrypt library, which handles all the happy primitives in a way that you can't shoot yourself in the foot. As for 'base64' being a good encryption algorithm? All the nopes & I can't evens. The password stuff is pretty bad too. IDK, needs a re-write.

elithrar 11y ago
A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang/issues/354 https://github.com/astaxie/build-web-application-with-golang... Web apps/services should use gorilla/sessions[1], securecookie[2], and Go's bcrypt/scrypt libs. [1]: http://www.gorillatoolkit.org/pkg/sessions http://www.gorillatoolkit.org/pkg/sessions [2]: http://www.gorillatoolkit.org/pkg/securecookie http://www.gorillatoolkit.org/pkg/securecookie
- tbiehn 11y ago
  Interesting. Not sure why you'd keep them intact. What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail. Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )
  - elithrar 11y ago
    gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc). Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.
    - tbiehn 11y ago
      Very cool, I'll have to take a look at the gorilla/sessions work. As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that. If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.
    - misiti3780 11y ago
      thank you for your hard work!
    - e12e 11y ago
      I wonder how long it'll take before we get usable TLS-based sessions again. AFIK the only way to do that now, is via client certificates, and the UI for that (on the browser end) is still so bad it's practically unusable. I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user). Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server). I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win". Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).
- BinaryIdiot 11y ago
  > A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang.. https://github.com/astaxie/build-web-application-with-golang.... That is incredibly unfortunate especially since much of the guide seems pretty decent.
  - elithrar 11y ago
    I disagree—the guide is Beego centric, and Beego does some peculiar things[1]. I feel like I'm ragging on someone's hard work here, but I take web security seriously, and I want to make sure frameworks (which are attractive to newbies) are doing sane things. [1]: https://github.com/astaxie/beego/issues/620 https://github.com/astaxie/beego/issues/620
    - Vendan 11y ago
      As a cyber security professional, that was an extremely disturbing read.
    - deleted 11y ago
      [deleted]
    - thewhitetulip 11y ago
      meanwhile I started to write my own little book on webapps with Go: https://github.com/thewhitetulip/web-dev-golang-anti-textbook https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
      - 0x434D53 11y ago
        Which also teaches horrible security practices. Pleas also use gorilla/csrf and not your own brown "solution".
        thewhitetulip 11y ago
        okay, you could be less insulting though

by tbiehn 11y ago

elithrar 11y ago

A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang/issues/354 https://github.com/astaxie/build-web-application-with-golang... Web apps/services should use gorilla/sessions[1], securecookie[2], and Go's bcrypt/scrypt libs. [1]: http://www.gorillatoolkit.org/pkg/sessions http://www.gorillatoolkit.org/pkg/sessions [2]: http://www.gorillatoolkit.org/pkg/securecookie http://www.gorillatoolkit.org/pkg/securecookie

tbiehn 11y ago
Interesting. Not sure why you'd keep them intact. What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail. Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )
- elithrar 11y ago
  gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc). Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.
  - tbiehn 11y ago
    Very cool, I'll have to take a look at the gorilla/sessions work. As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that. If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.
  - misiti3780 11y ago
    thank you for your hard work!
  - e12e 11y ago
    I wonder how long it'll take before we get usable TLS-based sessions again. AFIK the only way to do that now, is via client certificates, and the UI for that (on the browser end) is still so bad it's practically unusable. I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user). Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server). I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win". Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).
BinaryIdiot 11y ago
> A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang.. https://github.com/astaxie/build-web-application-with-golang.... That is incredibly unfortunate especially since much of the guide seems pretty decent.
- elithrar 11y ago
  I disagree—the guide is Beego centric, and Beego does some peculiar things[1]. I feel like I'm ragging on someone's hard work here, but I take web security seriously, and I want to make sure frameworks (which are attractive to newbies) are doing sane things. [1]: https://github.com/astaxie/beego/issues/620 https://github.com/astaxie/beego/issues/620
  - Vendan 11y ago
    As a cyber security professional, that was an extremely disturbing read.
  - deleted 11y ago
    [deleted]
  - thewhitetulip 11y ago
    meanwhile I started to write my own little book on webapps with Go: https://github.com/thewhitetulip/web-dev-golang-anti-textbook https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
    - 0x434D53 11y ago
      Which also teaches horrible security practices. Pleas also use gorilla/csrf and not your own brown "solution".
      - thewhitetulip 11y ago
        okay, you could be less insulting though