no, passwords shouldn't be encrypted, you should store hashes, just use the django default auth app
On Sun, Aug 16, 2015 at 9:09 AM, Uri Even-Chen <[email protected]> wrote: > Hi Dennis, > > > > On Sat, Aug 15, 2015 at 7:35 PM, Dennis Lee Bieber <[email protected]> > wrote: > >> On Sat, 15 Aug 2015 12:47:17 +0300, Uri Even-Chen <[email protected]> >> declaimed the following: >> >> >To Python, Django and Speedy Mail Software developers, >> > >> >Is it possible to make Speedy Mail encrypted? I want mail to be encrypted >> >on the server, and only the user will be able to read his/her mail. The >> >user's password will be encrypted on the server and nobody will be able >> to >> >> Most systems I know of don't store the password on the server in >> the >> first place. They store a one-way hash generated from the password >> (possibly using a randomly generated salt that is also saved with the hash >> -- that is, rather than just hash "password" into "hashstring", they hash >> "saltpassword" into "otherhash" and prepend the "salt" -> "saltotherhash". >> When user comes to connect later, they match the user name in the password >> database, extract the "salt" from "saltotherhash", attach it to the >> password given by the user, generate the hash, and see if it matches the >> rest of the saved hash). The hash value is only used for matching >> purposes, >> not for any subsequent processing -- it is not a cryptography key, nor is >> any cryptography key used to produce it. >> >> > Thanks for the feedback. Actually the passwords on my webmail in 2000 to > 2005 were not encrypted, but I agree with you that passwords should be > always encrypted. > > > > >> >read the user's mail except the user himself. Is it possible? When I had >> >> How do you intend to handle new inbound email? After all, the >> sender of >> the email sure won't know about any user encryption key -- that means you >> have to have the encryption key stored on your server associated with the >> recipient username, so that you can encrypt inbound email before putting >> it >> into the user's mailbox... Do you also intend to encrypt the header >> information or just the body of the message? >> >> A public key system MIGHT support that, in that the public key -- >> used >> to "send to" the recipient is only used to encrypt the data, and can be >> stored on your server (in the same username/password account file). The >> private (decryption) key would have to be stored on the user's computer >> and >> never provided to your server machine -- and you'd need some way to send >> individual encrypted messages to the user where they are decrypted on >> their >> computer, NOT ON the server. You'd also need to be able to identify which >> messages are new, read, deleted -- if the mailbox is encrypted, this >> likely >> means each message is a file within the mailbox, since you can't do things >> like mark and compress an MBOX (all mail is in one file with a special >> header marking the start of a message) file without corrupting the >> encryption stream. >> >> If, at anytime, the decryption key is on the server, you have >> lost the >> security you claim to be striving for -- as any court ordered system could >> just patch in a packet sniffer and wait for your user to connect, capture >> the password, and capture the decryption key if it is sent to the server >> to >> retrieve mail (though they don't even need it at that point -- they could >> just capture the decrypted contents being sent to the user... TLS/SSL >> sessions may alleviate that problem, but it does mean having certificates >> to initiate the TLS session keys). If the packets are TLS encrypted, they >> can require one to patch into the server at the point where the contents >> are converted back to plain text and capture the traffic. >> >> Of course, this now means the user has to carry around a >> "keyring" that >> can be accessed by any computer used to read the email (since the >> decryption key can not be on the server, if they read email from an >> android >> tablet they need to have the key installed on the tablet; they also need >> it >> on their desktop if they use it to access the server; on their phone if it >> has a browser, etc.). >> >> A Javascript client is probably going to be rather slow at >> decrypting >> the emails -- but you may not be able to install a compiled Java >> encryption >> package on all the clients out there (you'd have to have something for >> iOS, >> something for Android, for Linux, Macintosh, and Windows -- though the >> latter three might be able to use the same core Java code). >> >> We've taken care of inbound email. What were your plans for >> outgoing >> email? You can't encrypt that as it is going to other systems and other >> users who are not part of your server and don't expect to see encrypted >> stuff. You could perhaps store the already sent messages using the same >> public key, but you can't do that with in-work drafts stored on the server >> prior to being sent (at least, not without requiring them to pass from the >> server to the client for decryption and then back to the server in >> plain-text for delivery -- deleting the draft copy and saving an encrypted >> sent copy) >> >> I think ProtonMail <https://protonmail.ch/> is doing something similar > to what I want, so maybe I'll check what they are doing. I also want the > user's mail to be searchable, like Gmail. > > >> >I believe a user's mail is something personal, like his thoughts. I don't >> >want the police to read my mail and it's similar to reading my thoughts. >> > >> And the solution, in my mind, is to not use a central mail >> repository >> (no webmail client, nor even an IMAP client) and always do a >> delete-from-server when the POP3 client fetches the mail (and the server >> should do some sort of secure scrub of the deleted file area on disk). >> That >> way the only mail that will ever be found on the server is the mail the >> user hasn't logged in to retrieve yet, or outgoing messages that the SMTP >> daemon hasn't gotten around to forwarding to the destination (and deleting >> once the receiving server ACKs the message). (This also reduces the >> storage >> needed by the server, and likely speeds access to mail if using MBOX >> format >> as it doesn't have to scan humongous files). >> > > Yes, but then the mail is on your computer, and the police can enter your > house and take it (but you can encrypt it on your computer). There is no > way to have 100% security against the police. > > Uri. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAMQ2MsF73cgTQ-dyZ2thF%2BGsLqSjjAQDTDjo4OLbNY%2Bdid%3DLgg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAMQ2MsF73cgTQ-dyZ2thF%2BGsLqSjjAQDTDjo4OLbNY%2Bdid%3DLgg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tLEOXZnAybQ38c%3DgWNAWGPEY2QeNc2nzxoQsj3x7VEkxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
