First, the expression "password" usually refers to "bad entropy, relatively easy to brute force". And basically the only way to deal with this is to use a decent key derivation function, which is designed especially for passwords. Examples are script, bcrypt or PBKDF2. The main difference to other key derivation functions is that you can tune up the process to actually take a long time - which is wanted in this case.
So, that leads to the first problem: What kind of key derivation do they have? I couldn't find it on their page. So probably, they don't have any.
Considering their "one time authentication", my guess is that they just offer the option to use MAcs. And they use HMAC-SHA1 for this, which is quite on the lower border of acceptable - for legacy systems but not for current development. SHA-1 should not be used today any more, but in HMAC it is not broken so far. But developing a new system should not actually involve such an outdated hash function.
And then: They use $(IV + KEY)$ as the key for the HMAC, which seems not that great either.
That last part actually leads me to believe they don't have session keys but just use that passwords (called $KEY$, I guess) directly, and maybe for both encryption and integrity check.
And then I stumbled over this discussion, which gave a little inside in their development of security features: github
Oh, and it seemds they are using libsodium as cryptographic library. And that one already gives you pretty much everything you would want: KDFs, key exchanges, state-of-the-art encryption and hashes, previously mentioned scrypt, etc. I don't know how good those implementations are, though.
Interestingly, there you can also find the term "onetime authentication" (link), which doesn't really make that much sense. But there you can find this:
Finally, Poly1305 is not a replacement for a hash function.
Building an HMAC out of this sounds weird.
Overall, it doesn't look too good, and probably their security is lacking.
Coming back to yout questions:
- Passwords should never be used as key directly, which might be what they do. And then it depends if your password actually has full entropy(uniformly chosen of all strings of length 28). In that case it should be fine. If it is words in language, that's entirely personal preferance.
- AES 256 has a key size of 256 bit. The question is if they use actually the full size. If they use a password in base 64 encoding as key directly, that would be really, really terrible. Strength of security of AES is: Unbroken, don't worry about it. More of a problem could be their mode of operation, because you would actually want an authenticated one.
- Well, using AES as standard is a really good thing. Supporting other ciphers is quite common. However, I doubt your statement, that we're heading into the direction of Bernstein's Chacha or Salsa ciphers. AES is the de-facto standard for state-of-the-art symmetric encryption.
- It should, but I have doubts that this is done in Shadowsocks.
- This isn't a consideration, because the encryption scheme is almost surely not the weakest part of their system. Security depends only on the weakest link of the system, and it is basically never the encryption scheme. One other possibility is wrong usage of an encryption scheme (e.g. hard coded key), maybe have a look here.
- Well, that depends on how much you already know. For starters, Wikipedia has a really good quality for a lot of cryptographic topics. Then there are online courses for cryptography, books like Applied Cryptography by Bruce Schneier, etc. Most importantly, focus on scientific publications and try to spot and avoid amateur publications. Other than that, it mostly depends on the time and effort you are willing to invest.
