Q:

Encryption example with password only ... no Salt.  Does it work? 

I have been doing some research on creating an encryption/decryption class for use in .NET application.  Time after time I read that a salt was needed in addition to the secret password.  Today I have come across an encryption/decryption method that only makes use of a single password.  Is there something wrong with the encryption methods used by this code as it does not seem make use of a salt? 
Public Shared Function EncryptString(ByRef input As String, ByRef password As String) As String
  Dim RijndaelManagedObject As New RijndaelManaged
  Dim crypto As ICryptoTransform, MD5Obj As New MD5CryptoServiceProvider
  Dim EncryptedBytes As Byte()
  Dim HashedBytes As Byte() = New ASCIIEncoding().GetBytes(password)
  Dim PlainTextBytes As Byte() = New ASCIIEncoding().GetBytes(input)

  RijndaelManagedObject. BlockSize = 128
  RijndaelManagedObject. KeySize = 128
  RijndaelManagedObject. Mode = CipherMode. ECB
  RijndaelManagedObject. Padding = PaddingMode. Zeros
  RijndaelManagedObject. Key = MD5Obj. ComputeHash(HashedBytes)
  crypto = RijndaelManagedObject. CreateEncryptor()
  EncryptedBytes = crypto. TransformFinalBlock(PlainTextBytes, 0, PlainTextBytes. Length)

  If EncryptedBytes. Length > 0 Then
    Return Convert. ToBase64String(EncryptedBytes)
  Else
    Return String. Empty()
  End If
End Function

A:

This code has a number of flaws:

If input or password are not ASCII a silent degradation occurs.  In particular non ascii input won't be decrypted correctly. 
You don't use many iterations, this means that brute-forcing if really fast. 
The lack of salt is harder to expoit here than with password hashes since the hash is not directly known.  But if you encrypt files with a known beginning block(which is common with many file headers) then one could build a rainbow table for this one format.  But as always rainbow tables don't gain you anything if you just try to crack a single file/hash.  They only gain if you need to crack many different passwords used in the same way. 
The ECB mode isn't recommended, since it encrypts each block separately.  This makes the problem of 3) much worse, since you just need to know the plaintext of any block to build a table.  In particular the last block usually has low entropy.  I'd expect every 16th set of data to have only 8 bits of entropy in it.  Ouch. 
I'm not sure how PaddingMode. Zeros works.  But it might not be possible to strip the padding since its length isn't encoded.  So you might have some additional 0 bytes after decrypting. 

The Electronic Codebook (ECB) mode encrypts each block individually.  Any blocks of plain text that are identical and in the same message, or that are in a different message encrypted with the same key, will be transformed into identical cipher text blocks.  Important:  This mode is not recommended because it opens the door for multiple security exploits.  If the plain text to be encrypted contains substantial repetition, it is feasible for the cipher text to be broken one block at a time.  It is also possible to use block analysis to determine the encryption key.  Also, an active adversary can substitute and exchange individual blocks without detection, which allows blocks to be saved and inserted into the stream at other points without detection. 

A:

No, there's nothing wrong with this. 
Salting passwords is to prevent rainbow table attacks when you store those hashed passwords.  In this case the password is being used to generate an encryption / decryption key and is not being stored.