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 <u...@speedy.net> wrote: > Hi Dennis, > > > > On Sat, Aug 15, 2015 at 7:35 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com> > wrote: > >> On Sat, 15 Aug 2015 12:47:17 +0300, Uri Even-Chen <u...@speedy.net> >> 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 django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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.
