Comments for ClairVoyanT SysAdmin
Re: This is a really, *really* bad idea.
Uhm... a total rsa encryption with a passwords file filled with a list of oneuse passwords is better...
Re: This is a really, *really* bad idea.
> Uhm...the idea of a simple signature is
> unsecure, can you tell me how to break
> the security of a signed email that is
> created by one-use passwords and
> commands?
> The password changes every time CVTSA
> receives an email, so nobody cound use
> captured emails.................
Oh, good! That prevents replay attacks, and usage of a captured password. It does /not/ prevent command messages from being modified in-flight, and commands are still plaintext and so any information within them need be considered public -- but nonetheless, it's a very big improvement.
Re: This is a really, *really* bad idea.
Uhm...the idea of a simple signature is unsecure, can you tell me how to break the security of a signed email that is created by one-use passwords and commands?
The password changes every time CVTSA receives an email, so nobody cound use captured emails.................
I think that it is enough safe....
I'm working to this and to other security features, and as I promised the new releases will contain them....
Re: This is a really, *really* bad idea.
> If you use any type of encryption you
> will not able to send emails from
> everywhere.
GnuPG runs on laptops and a great many handhelds. As for sending email from other computers, one can easily carry a copy of GnuPG and one's (password-encrypted) key on a keychain flash device or like portable, USB-enabled storage.
Not that encryption and signature validation are enough -- one would also want some kind of replay attack prevention before this system could be considered even marginally secure, as otherwise a malicious individual could replay legitimate, properly signed messages originally sent by an authorized system administrator at times when running those same commands would be undesirable.
I appreciate that you're trying to write tools to make system administration easier -- but publishing such tools without giving thought to the security implications of their use is every bit as irresponsible as giving a public seminar encouraging individuals to leave their houses unlocked when they go out to ensure easier access when they return home.
Stable Version
In the next two version before the 0.2 I'll fix all bugs I find; If you find a bug or a problem,[or something you don't like ] please contact me. Your help is need to build a usable stable version. Thanks.
Paolo.
Fetcher function
I need to know the opinion of somebody uses CVTSA about the fetcher functions. CVTSA allows you to fetch emails with some fetcher (as fetchmail) that stores received datas in a file in plaintext.
I don't find it very useful....
My question is: do you want that I remove fetcher running mode?do you use it?
Thanks for your time.
Re: This is a really, *really* bad idea.
If you use any type of encryption you will not able to send emails from everywhere. Infact if you want to send emails using WAP system it's very hard to encrypt datas. I wanted to give a simple way to run commands from every place and at every time, and I know that the security features are not very performant :) But If you read the "todo" file you can see that I'm trying to find new security features; so I appreciate a lot your comment and your idea of encryption that will be added in next developping releases(now I'm trying to reach a stable release).
This is a really, *really* bad idea.
Sending passwords in email in plaintext (without so much as challenge-response verification)? Trusting a denied command list and an accept list of *email sources* to provide any real measure of security?
Okay, granted, I'm paranoid -- but I'm *professionally* paranoid, and this is a Really Bad Idea. If nothing else, it provides a trivial way for someone who breaks into the mail server (or sniffs one of the command messages) (or who breaks into one of the *clients* and observes the content of a command message it receives) to break into the rest of the network.
At *ABSOLUTE MINIMUM*, this software should *at least* use asymetric encryption and signing on the command messages (GnuPG would be a good way to do this). As it presently stands, it absolutely should not be used in anything intended to even vaguely resemble a secure environment.
Send your scripts...
IF YOU HAVE WRITTEN USEFUL SCRIPTS YOU CAN SEND THEM TO ME AND I'LL RELEASE A SPECIAL PACKET CONTAINING A COLLECTION OF ALL BEST SCRIPTS. SEND THEM TO ardoino.gnu@disi.unige.it