1. 6

We made a little list of our favorite SaaS services. Anyone here in the Lobsters community working on a project that you’d like to suggest?


  2. 3

    I’m currently working on https://developermail.io - an email-SaaS that is configured with git - might be referred to as the “Heroku for email”.

    I’d apprechiate if you consider adding it to your list!

    1. 3

      Oh cool! I love stuff like this - will bear in mind in case the need arises.

      Other than exposing the sieve rules over git, how do you compare to fastmail offering more-or-less the same featureset / price point?

      Your security page claims you use SHA-512 for password storage.

      My understanding of crypto is… not deep, but that looks like poor marketing given http://security.stackexchange.com/questions/52041/is-using-sha-512-for-storing-passwords-tolerable is one of the first things I came across trying to figure out if it was OK.

      1. 2

        The unique selling point would be the git configuration, including all the advantages that git brings: You know who changed what when, you can have review processes using branches/ pull-requests, rollback changes and do bulk changes more easily. Plus you can comment your configuration. Plus: It feels more natural and leet for developers :)

        Additionally, as you pointed out, the sieve control is way more powerful.

        1. [Comment removed by author]

          1. 2

            That’s a good thought. developermail uses rounds=100000, so this should probably be mentioned on the site.

            1. [Comment removed by author]

              1. 1

                From what I know, the used number of rounds can be treated similar to the salt. It’s not required to be hidden, as it’s stored alongside (or at least accessible with the same credentials/ from the same applications) in the system (in fact: CRYPT-SHA512 stores it in the form CRYPT-SHA512$6$rounds=xxx$HASH. In case of a data-breach security shouldn’t rely on the salt or whether the number of rounds are known.

                While I don’t agree with “security by obscurity”, I don’t want to escalate the discussion here.

                Thanks for your feedback!

        2. 2

          Regardig your observation for SHA-512:

          Obviously, one would want to have script or bcrypt, maybe even Argon2 instead of SHA-512. There’s however another factor when choosing the right algorithm in my opinion, and that’s the implementation.

          Let’s take dovecot as an example. According to the documentation SHA-512 is the strongest scheme implemented on all platforms (it mentions bcrypt but with the annotation that it’s not available on most Linux distributions). Furthermore, a Argon2/ scrypt plugin is mentioned, but it’s third party. Of course I’ve considered using one of the mentioned algorithms, do not feel competent enough to review a 3rd party plugin on my own regarding its implementation - Especially since dovecot itself was recently reviewed and received an extremly positive rating. A bad implementation of a secure algorithm may introduce other attack vectors or security issues. In case I missed something, I’d apprechiate feedback. And of course I’ll follow the ongoing implementation and new security features closely to improve the security whereever possible. I’m also wondering how other email providers handle the issue. Most of them are pretty silent on what algorithms they’re using from what I’ve observed. As anyone some insights to share?

          TL;DR: I’d love to use scrypt() but I’m not sure whether to trust the inofficial plugins implementing it.

          Edit: developermail.io uses rounds=100000. While one would still prefer scrypt(), this should increase computational requirements a lot. I’m going to add this to the website.

      2. 3

        Would love to get added under the Infrastructure category!

        We’re a bootstrapped SaaS startup: packagecloud.io trying to be the best and easiest to use package repository for a variety of languages and platforms, such as Redhat/Debian, Rubygems, Java/Scala/Clojure, and Python. We have a Unified API across all of your packages and repositories, with libraries available for most languages.

        Thanks in advance!