SSH v. SRP

A reader asks, "We've all heard of SSH. My question is whether SSH is really the best option, or the only option? Many security experts and cryptographers believe SSH users may be lulled into a false sense of security, because of some outstanding security issues. An open-source project based at Stanford purports to have solved these problems."

The Stanford group claims SRP to be safe against snooping and immune to reply attacks. SRP exchanges a session key in the process of authentication, provides mutual authentication to resist dictionary attacks, offers what is supposed to be perfect forward secrecy, and does not require the server host to keep any information secure. This comparison of these two technologies should provide food for thought. Can SRP replace SSH? Does it truly offer more security? Is it the better choice? In simple terms, what are *your* thoughts?

Comments

SSH has been banged on for years

[noeld]

As the subject says ssh has been banged on for years there is now even an OpenSSH project. This is time tested.

This counts a lot in my book, even if SRP is better in some areas, how well is it going to stand up when it starts getting banged arround.

Noel

RootPrompt.org -- Nothing but Unix

Re:SSH has been banged on for years

[Furry Ice]

True, the SSH implementation has been around for a long time, and there aren't any SRP implementations that I consider high quality (more later), but this doesn't mean that one can't be written. The simple fact is that the protocol is quite simple and appears to be equivalent (if I remember, it was proven to be equivalent) to the Diffie-Hellman problem, so the mathematics are solid--have been banged on for years, one might say. However, we just need a good, pervasive implementation, which would be a good project for the community. SRP isn't encumbered by patents and provides a lot of flexibility for encryption options.

For those who don't know, SRP just verifies the identity of a user to a server and, optionally, the server to the user. However, the process of this verification also _securely_ produces a shared symmetric key at both ends of the connection which can then be used to encrypt the rest of the session using a cipher of choice. Encryption is optional, if only secure authentication is required.

It's time we stop letting the fact that there aren't well ironed implementations of the protocol prevent us from using it. The main problem with the existing implemenatations from Stanford is that they require too many changes to the system (su, login, passwd, and some others) all have to be replaced with SRP aware versions, and yet another password file has to be created (/etc/tpasswd). PAM can probably relieve some of these problems (there used to be an SRP PAM module--is it still around?), but most of the difficulty with SRP lies in integrating it with your system. If we worked on simplifying this a bit, it could potentially be a very good solution.

Re:SSH has been banged on for years

[tjw99]

PAM modules are available for the EPS password format (which SRP uses on the backend) and are in fact the preferred way to set things up. If you have ideas for simplifying integration, I'd certainly like to hear about them.

Does it offer session encryption too?

[r-dass]

I know SSH used properly can encrypt your entire session so your entire session would not be suseptible(sp?) to sniffing. Does SRP offer the same? And what about the openssh project?

Re:Does it offer session encryption too?

[tjw99]

SRP telnet/ftp both encrypt your session to protect data confidentiality and prevent session hijacking.

Can SRP shroud X connections?

[Mike Greaves]

SSH can protect connections to remote X clients. Can SRP do this too?

ssh -r and -l

[Spoing]

#man ssh

-L port:host:hostport
Specifies that the given port on the local (client)
host is to be forwarded to the given host and port
on the remote side. This works by allocating a
socket to listen to port on the local side, and
whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
remote machine. Port forwardings can also be spec-
ified in the configuration file. Only root can
forward privileged ports.

-R port:host:hostport
Specifies that the given port on the remote
(server) host is to be forwarded to the given host
and port on the local side. This works by allocat-
ing a socket to listen to port on the remote side,
and whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
local machine. Port forwardings can also be speci-
fied in the configuration file. Privileged ports
can be forwarded only when logging in as root on
the remote machine.

Add tuneling, and I think your points are easily addressed.

Re:ssh -r and -l

[SL Baur]

Who moderated this up? This post is wrong. The -R and -L flags are used for tunneling, not specifying a port to connect to on the remote machine.
The -p flag specifies a port to connect to, however, it requires an sshd to be connected to it. There is no ssh equivalent for 'telnet host port'.

$ telnet ftp.xemacs.org ftp
Trying 207.96.122.8...
Connected to gwyn.tux.org(207.96.122.8).
Escape character is '^]'.
220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]

$ ssh -p 21 ftp.xemacs.org
Bad remote protocol version identification: '220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]

Re:Telnet is the only solution.

[slashdot-terminal]

Telnet, unlike its "secure" counterparts, is the only communications program that lets you connect to any port of the destination computer, regardless of application protocol.

I would think that SSH is limiting in that manner if you wish to test some daemon or something in security than it would be good. Also each and every public type machine that I have ever used and all unix machines I have never used have never either made ssh avaible or it was not really practal. SSH is only useful if you regularly connect to remote unix machines that support it or you have multiple machines with shell access.

That is simply not an option for me.

Therefore, the question:
Do we want to sacrifice our liberty for the sake of security? Not Thomas Jefferson, nor do I

*partial sarcasm*
Well considering how probably most of the people on slashdot are most likely on the FBI's most wanted list or are agents of the Iranian government trying to export 128 bit RSA I would think that they like it.
*end partial sarcasm*

Telnet With S/Key

[n3rd]

Even though I haven't used it often, telnet with S/Key login seems to be a great alternative to vanilla telnet.

From what I understand, it's only vulnerable to TCP hijacking (most things are) and dictionary attacks (which can be easily detected or accounts can be configured to be "locked out" after X bad login attempts).

The best one of these is OPIE which can provide a one time pad for telnet, FTP and even su.

Better yet, OpenBSD comes with this feature built into the OS.

Re:Telnet With S/Key

[Chang]

While S/Key and other one-time password systems are a great idea for people who need to roam, unencrypted channels like telnet are still not a good idea. You can learn plenty of useful information just by watching telnet traffic.

With the recent relaxation of encryption regulations in France and the U.S., the time has clearly come for all distributions to include encryption options right out of the box.

Re:Telnet With S/Key

[Inoshiro]

Uhm, that's just a login thing. Saying that you have a one time pad (because telnet is clear) to login is still no substitute for SSH. If you type "su," or do anything requiring a password, people will see it (although the S/Key su fixes that a bit). Ditto for any sensitive files edited or viewed, or anything else that is typed or displayed. It's like giving your credit card out over a cell phone. Don't do it.
---

Re:Telnet With S/Key

[petej]

Here's the l0pht advisory detailing cracking of s/key keys.

Also, isn't a one-time pad a very different thing from a one-time password?

Re:Telnet With S/Key

[n3rd]

I agree with Chang and Inoshiro; a non-encrypted datastream is a bad idea. As they stated, sensitive documents, su and gobs of other information can be found by sniffing the connection. If the actual data stream isn't encrypted, anyone with a sniffer can see anything you do.

The reason I like S/Key is because telnet clients are standard on almost any OS you can name. This makes accessing things such as personal (but not too personal!) e-mail easy from any machine on the Internet.

I personally use SSH the vast vast majority of the time, and only resort to S/Key if there isn't an SSH client available or I'm too lazy to download/install one. If I had to choose, it would be SSH hands down, but it's a pain not having the client on every machine (unlike telnet).

petej, the link to the advisory look interesting, however I'll have to check it out after I get home since the clueless IT Security folks here watch for hits on certain web sites (L0pht's being one of them). From my reading, I've seen the term "one time pad" and "one time password" used interchangably (sp?).

Re:Telnet With S/Key

[c o r e]

You're using something like s/key to protect your password from sniffing, yet you aren't concerned about TCP hijacking?

Anyone in a position to steal your password off the wire by sniffing can just as easily wait for you to authenticate and then hijack your session (they probably would wait until you 'su' to root though so they'll have that password after hijacking your session).

Encryption has more benefits than just confidentiality of passwords and sessions! It is a key ingredient in preventing session hijacking.

-core

It can't happen to me!

[HancockDC]

Regarding the ssh/srp comparison, I cannot evaluate whether I am dealing with a ticking bomb (by using ssh) or not.

What I CAN do is point out that the most dangerous security attitude is "It can't happen to me!" There is no substitute for watching the security web sites, making sure you have applied the latest security patches, and simply being aware of what is happening on your system.

ssh is a definite plus over telnet, and I use it routinely. It is now just as natural to me as using the telnet command was 10 years ago. I'll certainly keep an eye on any new ways of doing things, but it would take a little more than what I have seen so far to make a switch at this time
-----------------------------------------

Yeah there are some at tucows

[slashdot-terminal]

I would love to use SSH... problem is the machines I have to connect from. Is there any way to use SSH from a windows box. I would install SSH except all of the machines on campus are winblows boxes.

Actually if you look at your local tucows mirror you can get ssh type telnet shells. I know of at least one I saw being used but forgot the name.

Re:Yeah there are some at tucows

[Fluffy]

There's an SSH module available for Tera Term someplace. Incidentally, The Stanford guys use a modified version of Tera Term for their Windows SRP client. Last I checked, however, there were no SRP clients for MacOS, which IMO gives SSH a significant advantage with Mac clients like NiftyTelnet SSH out there.

I ran SRP daemons on my linux box for a while last year. It was relatively nice, supporting telnet and ftp, except it was meant as a replacement for your standard ftp and telnet daemons. This meant that things like dpkg would sometimes overwrite my SRP daemons when they decided it was time to upgrade ftpd.

Another disadvantage to SRP is that it creates yet another set of password files (tpasswd if I recall). If you installed SRP on a machine with existing user accounts, you had to reset the users' password for them to be able to use SRP. If you decide to disallow non-SRP connections, this can be a big problem.

Don't get me wrong, I liked SRP. I sniffed one of my sessions once and all that was displayed was garbage, which made me feel nice and secure. But I personally feel that SRP hasn't been around long enough, and isn't supported as widely as SSH.

Re:Yeah there are some at tucows

[Grand Facade]

Secure CRT?

Re:Yeah there are some at tucows

[TheTomcat]

I'm running an SSH client for Windows called SecureCRT. It works very well (key emulation is not 100%, but I can't even find a TELNET client that works properly). There's a 30day evaluation on Tucows.

Re:Yeah there are some at tucows

[xanth]

You can get the TTSSH plugin for TerraTerm. It supports port forwarding, rsa authentication, shosts, etc...

• TerraTerm
• TTSSH

Both are fully free.

SSH issues?

[freddie]

which are those? I've been ssh for quite a while, and the only thing I had heard about was a buffer overflow. Are there any questionable architecture design deciscions on ssh?

Also, does anybody have a mirror, it like this site is getting slashdotted already.

Re:SSH issues?

[Dr. Tom]

Here's a better SRP link:
http://berlin.arcot.com/srp/

Here's a python implementation of the protocol:
http://www.aist.go.jp/NIBH/~tomh/sr psocket.html

Re:Telnet is the only solution.

[EXTomar]

Naw...you can get SSH to connect through any port using SSH protocol and therefore encrypting the transaction. With this feature, you can encrypt many socketed transfers, like using "fetchmail" to get your email.

I look at SSH and I wonder if the protocol is generic enough to encrypt any stream. If it is, then why not write a ENFS(Encrypted NFS) file system for the kernel? You could theoretically use SSH-like schemes to authenticate and encrypt.

SSH, what a misnomer.

[GoNINzo]

SSH - Secured Shell

There's been how many bounce attacks and remote security issues with it? I know they designed it to be encrypted, but how about following up on the 'Secure' part of the name! I ended up not running it BECAUSE of the security issues it caused!

--
Gonzo Granzeau

Re:SSH, what a misnomer.

[GoNINzo]

Just to justify myself, having gotten burned by sshd before (twice even. `8r/), I've included URL's to make you all snuggily happy.

Here's a buffer overflow.

Here's a bounce attack

Here's another one.

Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago...

--
Gonzo Granzeau

Re:SSH, what a misnomer.

[I R A Aggie]

Just to justify myself, having gotten burned by sshd before (twice even. `8r/), I've included URL's to make you all snuggily happy.

Oh, joy!

Here's a buffer overflow.

Quote:

Date: Thu, 5 Nov 1998 02:38:51 +0200

This message contains information relevant to people who compile ssh with --with-kerberos5. There is one or more potential security problem in the Kerberos code. These issues are not relevant for people who have not explicitly specified --with-kerberos5 on the configure command line.

Here's a bounce attack Here's another one.

Two examples of the same thing, from August and September 1997 and version 1.2.17. You realize that skript kiddies prey upon those who don't keep their software up-to-date?

Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago...

You mean this CERT advisory dated 13 Dec 1999?

Quote:

Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code.

I think the lessons are:

1. Keep your software up-to-date.
2. Don't believe for a moment you're completely protected.
3. Keep informed of the latest in security threats.

The only completely safe computer is one that is incapable of being turned on.

James

Data encryption

[Boolean Tryst]

Quick thought on SRP vs SSH. From the quick glance at the SRP web site, it seems to me that SRP only offers secure password transmission and forgoes on packet encryption, offered by SSH. The two solutions differ very much. Therefore I could still be able to sniff yyour traffic and possibly gleam other important info, after the login ( su anyone ??? ). Note, I did only glance at the site while munching my lunch at my desk while troubleshooting a networking issue and chatting on IRC.

Re:Data encryption

[nconway]

Well, I don't know either, but I think this quote from the article indicates that SRP *does* offer session encryption, not just secure password transmission.

3.SRP exchanges a session key in the process of authentication. This key can be used to encrypt the user's login session and protect it from both snooping and malicious active attack.

ssh does a similar thing - a session key is changed and can be used for encrypting the user's login session, etc.

Re:Data encryption

[ajm]

The telnet and ftp implementations they offer do provide session encryption. However, to get hold of these you have to be a US/Canadian citizen and email them. Getting the source looks even more difficult.

Re:telnet rulez

[_fuzz_]

So you send your root password over the internet in cleartext? Now that's living on the edge... of stupidity. Have you ever used a packet sniffer? The output looks like this:

[anonymous@coward /]$ su -
Password: ontheedge

[root@coward /root]#

Next thing you know, you're taking part in a DDoS attack.

Security

[jd]

Here is a crude list of the various options. It's not complete, and it's not meant to be. The opinions I express are my own - I bought them for 5 cents each at the corner market.

• SSH 1.x - Offers a nice, basic, secure link to a computer. There have been claims of buffer overruns, for some versions, but these have either been fixed or don't exist.
• SSH 2.x - A supposedly less restricted version of the above, but with a licence that makes me wonder. Still, it's a very nice security package.
• OpenSSH - A genuinely Open Source clone of SSH 1.x.
• LSH - A genuinely Open Source clone of SSH 2.x
• Kerberos - A serious network-buster, by all accounts. The overhead is high. On the other hand, the logo is cool, and it has been stress-tested.
• NIST IPSec - Would you trust a Government-produced encryption package? Besides, it's way out of date and the maintainers would make snails look like international sprinters.
• FreeS/WAN IPSec - Encrypt ALL your connections irrespective of the package you're using. VERY nice and VERY powerful. Needs to be installed at both ends, but that's true of all software, really.
• EnSKIP - Same as IPSec, comes with the International Kernel Patches. Faster encryption than IPSec, in some cases. The original EnSKIP code isn't maintained, so I hope the kerneli people are doing something with it.
• TCFS - An encrypted file system, linking two or more computers. If you're wanting to share files, this is probably a good bet.

Re:Security

[AppleJuice]

FreeS/WAN IPSec - Encrypt ALL your connections irrespective of the package you're using. VERY nice and VERY powerful. Needs to be installed at both ends, but that's true of all software, really.

Actually, FreeS/WAN does not necessarily need to be installed at both ends (although, to ensure best results...). It has been shown to work with more than a few commercially available IPsec implementations. You just need to tweak things a little, but that's true of all software, really. One thing though, 3DES is a must for this to work (often a BIG issue).

Re:Security

[Hawke]

Nice list, but you are comparing apples to oranges without pointing out the differences:

• SSH - Encrypted the telnet session. Supports but does not require better authetication, but does not provide a central authority.
• Kerberos - Provides centralized authentication. I believe your connection is still vulnerable to sniffing, but could be wrong.
• IPSec - Provides an Point-to-Point encrypted network link. Where SSH just provides a single TCP/IP stream, IPSec can provide a whole interface. Authentication options for IPSec vary.

Re:Security

[SEAL]

The most recent problem with SSH 1.xx and OpenSSH is that they link against RSAREF which was found to have a buffer overflow. As I recall, this was exploitable only in conjunction with another problem that existed in SSH 1.xx. Also, there was a patch that RSA gave their blessing to... you can probably dig up info at http://www.securityfocus.com - just search in the bugtraq archives.

SEAL

Re:Security

[Ded Bob]

OpenSSH - A genuinely Open Source clone of SSH 1.x.

I believe OpenSSH is not a clone but a split. They took an earlier version of SSH with a BSD license and patched it up. I don't recall which version of SSH it is based upon.

Re:Security

[logicTrAp]

Kerberos itself doesn't guarantee that a connection is encrypted but as a matter of course most kerberized applications do encrypt traffic.

Re:Security

[Zoinks]

Useful list, but you never mentioned SRP! Anyway, last I read about SRP it was only a means for secure authentication and had nothing with encrypting the link. SSH, of course, does a whole lot more, like providing secure host-to-host TCP tunnels, in addition to secure authentication. The key improvement of SRP was that compromise of the remote host's "password" database would be of no use to the thief.

Re:Security

[Brainchild]

The most recent problem with SSH 1.xx and OpenSSH is that they link against RSAREF [...]

SSH 1.2.x only links against RSAREF if you tell it to. This is only an issue for places where the RSA patent is valid (which, by the way, expires in September of this year).

OpenSSH doesn't link against RSAREF. It links against OpenSSL, which may or may not link against RSAREF, depending on how it was compiled. Again, same patent deal applies. Regardless, if i recall correctly, the problem in RSAREF did not affect OpenSSL (and hence OpenSSH), only SSH 1.2.x

In short, RSAREF is only a potential problem if you use SSH 1.2.x in the USA until September.

Re:If only I could SSH

[Mr. Protocol]

Yes, SecureCRT from VanDyke implements SSH protocol as well as Telnet. Very good terminal emulator.

Re:If only I could SSH

[jschauma]

There is an SSH-Plugin for TeraTerm Pro.

Re:If only I could SSH --- You can

[Phil Hands]

Check out mindterm (a Java SSH implementation) and PuTTY (a Free Windoze Telnet/SSH)

Re:If only I could SSH

[Masem]

Get TeraTerm Pro (FREE) from any tucows.com site, then go to the TeraTerm homepage, and follow links for a FREE SSH addon for TeraTerm. I've been using it for several years and have not been disappointed.

Re:If only I could SSH

[andersen]

For windows, grab Tera Term Pro (which is free), then grab and apply the SSH patch. Like magic you can now ssh from your windows boxes.

Re:Telnet is the only solution.

[Anonymous Coward]

If you want to send data to arbitrary ports, that's what netcat is for. You don't need telnet.

Re:If only I could SSH

[Eric.pl]

This is the readme of what we use here :

$Id: readme.txt 1.13 1998/06/30 13:36:45 c.igaly Exp c.igaly $

SSH Windows Client, version 24-June-1998

PLEASE, READ THIS TEXT. I DO NOT WANT TO SPEND TIME REPEATING SAME THINGS ALL OVER AGAIN.

DISCLAIMER
--------------------

THIS PROGRAM IS FREE. IF YOU ARE NOT HAPPY WITH CONDITIONS OF ITS USE, PLEASE DO NOT USE IT.

Source: You can freely use this program. Source is not available and I am ignoring all e-maill messages with request for it. If you dislike such policy, please feel free not to use it.

This program is distributed AS IS, and as such the author shall not be held liable for any loss of data, down time, loss of revenue or any other direct or indirect damage or claims caused by this program.

This program is not supported and there is no warranty or claim of fitness or reliability. I am trying to fix obvious bugs or improve it from time to time but I have no plans to do this on regular basis.

Bugs: This version is not crashing my system. At least not more than compiler(s) I've used to make it :-)))

Crypto Library: This program is using Peter Gutmann's Cryptlib. You can download last version (2.0) from ftp://garbo.uwasa.fi/pc/security/cryptl20.zip. You can alse use older version but this one is not available on garbo.uwasa.fi. Try to look at http://www.doc.ic.ac.uk/~ci2/ssh for alternative location. Beta version 2.1 can also be used. At this moment Blowfish is not working because implementations in SSH and Cryptlib are not compatible. Remember that cryptlib 2.0 is using ODBC so you must have it installed. If you do not want to do that, use cryptlib 1.1 (16- and 32-bit versions) or 2.1 beta version (32-bit version).

================================================ ====================
Cedomir Igaly e-mail: c.igaly@doc.ic.ac.uk
Department of Computing
Imperial College of Science, Technology and Medicine
180 Queen's Gate London SW7 2BZ
United Kingdom
================================================ ====================
pub 1024/DA5CB241 1994/12/19 Cedomir Igaly
Key fingerprint = 73 F2 6D 64 75 13 FE F2 D8 12 10 D4 9C C2 F4 3D
Cedomir Igaly
================================================ ====================

Re:telnet rulez

[slashdot-terminal]

So you send your root password over the internet in cleartext? Now that's living on the edge... of stupidity. Have you ever used a packet sniffer? The output looks like this:

Maybe there's nothing that you care about on the machine. I had a thought I don't know about you but perhaps if you security gets compromised and someone was doing one of these fabled attacks then perhaps you could just shut down the machine or turn it off in the first place?

[anonymous@coward /]$ su -
Password: ontheedge

[root@coward /root]#

Who transfers to the root partition as part of their normal access or for su'ing?

Next thing you know, you're taking part in a DDoS attack.

Assuming you edit the file /etc/login.access or something like that you could just remove logins for root or anyone else from certain times. Bango you have removed the problem without expending any problems at all. Or perhaps you just use a complex C++ program that would analyze voice prints (ala Millenium "Forrest Green is People" *snicker*)?

PKI and other issues

[Signal 11]

The problem most people side-step or don't even know about is man in the middle attacks:

Works like this... you're host A connecting to host B but the packets go through host C. So unless host A and B have an alternate method to exchange keys, you're vulnerable to having host C replace the key with it's own, so in reality you're talking to host C and it's using a simple form of IP masquarading to make it look as if it's B or A...

So long as host C is the only route between the two (which is suprisingly easy to accomplish) - or through icmp and bgp manipulation makes that the case - you can ensure that host C has access to all the data over the wire even though those two hosts think they now have a trusted connection! Unless you can bypass host C via another path you won't even know it's happening.

Now, let me make this clear: there is no method for you to ensure data integrity over a public network like the internet. You must exchange keys over a secure medium before you can communicate securely over any network unless you can ensure that the entire network is under the same (trusted) administrative domain and have verified that it has not been tampered with (very, very difficult).

So in short: Yeah, SSH has problems. But this new program isn't going to make any leaps forward. You really need a PGP-style distributed key server system where you can verify the key's integrity through a trust network and/or via multiple independent routes / hosts. Otherwise, the alternative is a Kerberos-style system. Unfortunately THAT system has a single point of failure - if the key server is compromised your entire network is compromised. I'm not an expert though on Kerberos, so feedback is appreciated.

That is all,

Re:PKI and other issues

[Kaa]

Now, let me make this clear: there is no method for you to ensure data integrity over a public network like the internet. You must exchange keys over a secure medium before you can communicate securely over any network unless you can ensure that the entire network is under the same (trusted) administrative domain and have verified that it has not been tampered with (very, very difficult).

You seem to be confused (umber hulks are a problem in your area? :-) We, and you, are not talking about *data integrity* which is being sure that your chunk of bits got from point A to point B without having been changed en route. We are talking about authentication which is a hard problem, has been a hard problem, and will stay a hard problem for the foreseeable future.

Think about it this way. You, Alice, communicate with some entity at the other end of the wire. This entity tells you that it is Bob. Well, for this statement to be meaningful the label "Bob" has to refer to some entity that Alice knows of.

Now, if Alice and Bob-that-she-knows-of have a shared secret, Alice can test that the entity-on-the-other-end-of-the-wire is really Bob-that-she-knows-of. There are standard crypto protocols for this. However, consider the situation that Alice and Bob have no shared secrets. All that Alice knows about Bob is publicly available info. In this case Alice cannot be sure that the entity-on-the-other-end-of-the-wire is Bob-that-she-knows-of and there is no way for her to be sure.

Again, this problem has nothing to do with "data integrity over a public network". It all revolves around existence of a secret (=key) shared between Alice and Bob.

And, by the way, if Alice has a trusted PKI key server with a trusted path to it, then she can authenticate Bob easily enough over a different, completely non-secure network. That's all standard PKI stuff, really.

Kaa

Re:PKI and other issues

[iabervon]

SSH keeps track of the server public keys of sites you connect to and warns you strongly if the key has changed. Since the private key corresponding to the public key is used in the protocol, either the man in the middle is simply forwarding the traffic, which remains secure, or the server has been compromised, or the man in the middle is reporting a different public key for the server.

The initial connection is important-- you need to get the right server key the first time (and any time the server changes it). But in the usual case, you have an independent way of verifying that you're connected to the site you think you are in special circumstances.

Re:PKI and other issues

[tjoynt]

How difficult is it to implement a man in the middle attack in the real world? Is it script-kiddie level or NSA level? What conditions are necessary to carry it out?

Seperate question: is there any secure term client that uses PGP-style distributed keyservers transparently? Is one worth developing?

Re:PKI and other issues

[Chalst]

Kerberos v5 allows multiple domains, where the compromise of the
certificate authority only breaks authentication in that domain.

This is a good source of information on Kerberos.

Re:PKI and other issues

[Signal 11]

Aight, you got me. I screw up once with the wrong term and I got called on it. ;) Thanks for the correction.

Re:PKI and other issues

[Signal 11]

Well, if it goes through a router you can reprogram it to say "all packets to host X to go my port instead of the default port" in the ruleset. Any router between the source and destination can do, but the ideal scenario would be to compromise a router and a host on a network between host A and host B.

Assuming you can do that, all you need to do then is run your ssh proxy as root. Of course, I don't have the time/skills to write such a proxy, but basically all it would do is keep pre-generated keys in a queue and then dynamically assign them for each host and then setup a translation table to keep track of which "real" key maps to which "fake" one. After that, just dump the decrypted stream to disk or back out to a fourth host for later analysis.

Now, maintaining that route would be more difficult as many routers do BGP / dynamic routing. Forging /those/ packets is left as an excercise for the reader. ;) Go bug l0pht for details..

Re:PKI and other issues

[Jon Peterson]

Too many people either fail to make the distinction between authentication and encryption, or else feel that if you fix encryption then you fix authentication.

This latter belief appears to stem from the very shortsighted supposition that if you have an unguessable (not in crack files) password and always send it encrypted you'll be OK.

There are so many ways to get a password its not true. Passwords, while a good start, are not the be-all and end all of authorisation.

The public key authentication mechanism of SSH actually makes things worse, because the key is (effectively) tied to one or more computers rather being tied to the individual, which is almost always the wrong approach. Most authentication systems are trying to authenticate people, not computers - the fact that the same people often use the same computers is merely convenient - convenient for the computer system not the user.

Worse still, the public key, being digital, is easily copied without the owner knowing. Sure, it's password protected, but that just brings us back to passwords again.

So, for authentication I much prefer physical card based systems - i.e. two factor systems. You know when you've lost your card, you can keep track of who has cards, and you can't replicate stealthily.

SecurID is nice because it integrates well with existing systems - no special card reading hardware needed. Other such systems exist, too.

Sure, we need the encryption as well, but simply sending ye olde unix password over an encrypted channel is no magic solution to safe authentication.

Re:PKI and other issues

[Signal 11]

That's true, but the problem still exists.. that's just a partial solution. A true solution requires establishing a trusted path to the server, or a mutual trusted 3rd party to perform verification.

Re:PKI and other issues

[pjl5602]

Well, I wouldn't call the KDC a single point of failure as you can have multiple KDCs for your cell. But your statement is correct in that the system falls apart if the KDC is compromised. The KDC holds user's key for encrypting a TGT to be sent back to the user. If that key can be substituted, the user's account can be hijacked.

Pat

Re:PKI and other issues

[TheCarp]

> Most authentication systems are trying to
> authenticate people, not computers - the fact
> that the same people often use the same
> computers is merely convenient - convenient for
> the computer system not the user.
>
> Worse still, the public key, being digital, is
> easily copied without the owner knowing. Sure,
> it's password protected, but that just brings us
> back to passwords again.

I have to agree and disagree.

ssh IS a very good system. The public key system
it uses does work. However, it only works if
the user sets it up right. (of course it is
defeatable if someone can sit in the middle and
play with all packets...thats besides the point
and not always, or even usually feasable)

The security of the system is in the encryption
of the private key. The authentication is that
anyone with the private key, has to be me (is
assumed). So...if my key has a passphrase...only
me can ever open the private key and use it...
even though it is stored on multiple machines
(hopefully moved to them in a secure manner)
only I can unlock it on any of these machines.

Re:PKI and other issues

[ninoles]

After reading your e-mail and ssh/srp comparison, I even more appreciate the way the Debian project (will?) handle it:

The ssh authorized_keys is manage through LDAP. If a maintainer wanted to modify it, it should use its official GPG key to encrypt the files and mail it to the ldap server. Because the key is well trusted (it must be sign by another maintainer), we obtain, IMHO, a secure way to exchange keys, which permit the use of RAS-based authentification.

For sure, the Achille Heal is on the Debian Key Ring. If it became compromise, the validation is no more valid. However, as I said, each key who aren't in the original key ring must be signed by someone else already in the key ring *which has met* the developper physically. Moreover, the key ring is manage by a person who can verify the authenticity of any demand and the keyring is widely distributed through the standard distribution.

It seems, when reading the comparaison, that ssh is as secure as srp if rsa-based authentification is used. So, for the Debian Project, SSH is as secure as SRP. However, having an yet another open source alternative is a Good Thing(TM) and one of SRP goals is to be a standard interface for authentification, making it easy to incorporate into other applications. OTOH, I really don't know if it's hard to add ssh authentification into an application. Can someone could give me some examples of applications doing so (both ssh and srp) which is not an ftp or telnet client?

Thanks and sorry for my bad english, I'm just a bit tired.

Re:PKI and other issues

[Webmonger]

Wouldn't certificates solve this without PKI (or are they simply a form of PKI?).
1 Central signing authority D encrypts the public keys of A and B using its private key
2 A and B exchange signed keys
3 A decrypts b's key
4 B decrypts a's key
5 A and B exchange session keys
6 Communication starts.

Yeah, I know. Single point of failure.

Re:PKI and other issues

[Joshua Spoerri]

An interesting solution to this problem was just recently released: sfs, which allows separating the pki out from the connection protocol.

Re:PKI and other issues

[Jon Peterson]

The security of the system is in the encryption
of the private key. The authentication is that
anyone with the private key, has to be me (is
assumed). So...if my key has a passphrase...only
me can ever open the private key and use it...
even though it is stored on multiple machines
(hopefully moved to them in a secure manner)
only I can unlock it on any of these machines.

Doh! I said 'public key' in my original post and meant private key.

Anyway, my point was meant to be that if the private key is only protected by a passphrase we are back where we started with the weakness of passwords/phrases. I don't want to leave copies of my private key all over the place and protect them with a password. I want to keep my private key in my wallet and protected it that way IN ADDITION to a password.

Re:PKI and other issues

[TheCarp]

> I want to keep my private key in my wallet and
> protected it that way IN ADDITION to a password.

Well hell, add a "me too" on that. However,
even that scheme has its problem. The main
problme with it is hardware overhead.

It means that every machine you might wish to log
in from will need special hardware to read your
private key (unless you plan to type it in every
time)

I think that for most applications, and most
people, the ssh solution is "good enough" (of
course ssh doesn't say you can't put your private
key on a smart card or something...I am sure that
if you had a smart card reader it would be
trivial to change ssh to use it)

Take my current setup. my desktop has the
private key, with a moderately strong passphrase
(its not exactly random chars, but its not
going to fall to a dictionary attack or any
simple permutations)

If I remember right, an 128 bit hash is made of
the passphrase and used to encrypt the private
key. With a strong passphrase that is nearly
impossible to break.

more importantly.. the system is secure enough
that it would be easier to compromise the
machine or take me into an ally and beat me up
and force me to give them the passphrase then it
is to defeat it other ways... smart cards fall
to those exact same "methods".

Re:Telnet is the only solution.

[jbarnett]

Sure telnet can connect to any port, this is really great for testing out service "by hand" or to see if xyz host can connect to port xx on host zyx though the firewall. Sure telnet is invaulable for some things, but it is still unsecure.

For example, if you telnet into a server, su to root, do some root work, exit root account, read your email, exit the telnet session. If someone was sniffing your network they would have

1) you login and password
2) ROOTS! login and passowrd!!
3) the IP of the machine your telneted into
4) A rough idea of how you work, what "major" logs, info you check when you fist log on
5) that you girlfriend is pissed at you (via the email)
6) that your boss is pissed at you (via the email)
7) that pretty much anyone that emails you has some bitching to do about something (via the email)
8) how good of a typist you are.

Sure telnet is convent, but is insecure. If you do anytype of remote rooting(TM) you need SSH. I would highly suggest you use SSH for normal remote logs and ALWAYS use SSH when doing remote rooting(TM).

True story, I know a freind that used to go to college part time, and did Jr. level admin stuff for a local company. At school one day he was chilling at the computer lab after class, he got an email at his school's email account saying that their was problems with XYZ on the server at work and all hell was breaking loose. He quickly fired up Windows 95 Telnet, hoped over to the site in normal user mode, looked around and firgured out the problem. The problem needed root access, he shoved up the SU command without a thought, entered the password, fixed the problem, the bosses where happy.

The thing he didn't know was that there was a group of college security nerd playing around in the computer lab at the time, they where developing a Windows 95 ethernet sniffer. It was still beta, but it sure enough grab his password and also ROOT's password!!! They told him about it, and he promptly called an admin on site that changed root's password from the console, but if these security nerds in the computer lab where script kids or malice mother fuckers, who knows what would of happened!!

Sniffing is easy, try sniffit, a easy to use packet sniffer for Linux. When I was on help desk I used to sniff the admin computer and come up with all kinda of neat things. The thing I didn't want to find out though is that %90 of his day was involed in IRC chatting under the #lesbains channel with the nick Amy34Blonde (he was male).

Name one major hack based on an SSH weakness

[rambone]

Give me a break, these rips on SSH are almost completely groundless and in typical /. fashion, none of you really has a clue what you are talking about.

Yes, SSH has weaknesses and the occasional buffer overflow, but the patches are made fairly quickly, and because of the high number of people using it, there is a high probability that other people will find a bug before it affects you.

Re:Name one major hack based on an SSH weakness

[GoNINzo]

Groundless, eh?

Here's a buffer overflow.

Here's a bounce attack

Here's another one.

Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago.

And don't tell me that 'patches come out quickly' because the bounce attacks were not patched for several weeks, and I know, because I was hit with them. So it might sound like just hype, but there is proof out there.

And I forgot, just because URL's were not included, I have no clue, right? Happier?

--
Gonzo Granzeau

Differences...

[altair1]

SSH is a little more versatile in that it can do port forwarding to make
arbitrary TCP connections secured. It can even be used to support secure PPP
tunnels. SRP on the otherhand is less versatile. Only telnet and ftp seem to
be supported. Someone please correct me if I'm wrong, but as far as I know
SRP does not have any sort of connection forwarding like SSH does.

Another major difference is in licensing. SRP is under the GPL. No official
version of SSH is under a real open source licesense. SSH2 forbids any sort
of commercial use, even internally. SSH1 is slightly less restrictive in
that it allows for commercial use without paying them, but you can only use
it internally. These license restrictions are the reason SSH isn't found in
most linux distros.

However, there is an open source implementation of SSH being developed by
the OpenBSD people at http://www.openssh.org. It is ususably stable in its
current version.

The main thing SRP and SSH have in common is that they require no
infrastructure to be secure. In otherwords, you do not need any sort of key
distribution centers, or any other sort of software besides the daemon
itself and the client program to make everything work. Compare this to say,
Kerberos. Using kerberos, you can have secure connectivity to a machine,
however, there's a lot of additional infrastructure and complexity thrown
in, (such as KDC machines). You'll want to use Kerberos if you have a lot of
machines that will share a common user/password database. Kerberos will let
you log into one machine, say a kerberized workstation, and you'll be able
to securely log into any other machine (via telnet, rlogin, rsh, rcp, ssh,
ftp, pop3...) that's part of the same Kerberos realm without ever having to
type your password (assuming your client software supports Kerberos authentication).

SRP is arguably more secure than SSH, however SSH is a little more widely
implememnted and can be used for more things. If all you need is a secure
telnet and FTP, and the existing clients are suitable for you and you can
trust it (SRP is a litte newer), I'd give it a try.

Re:Differences...

[Anonymous Coward]

SSH does a P-K exchange (RSA) first then does authentication. SRP sends the username in the clear, then does something similar to Diffie-Hellmann and incorporates a hash of the password as authentication. Both are secure against password sniffing, but I like the first better because it also hides the username.

Re:Differences...

[joneshenry]

"SRP is under the GPL."

I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also states that srp is "free for both commercial and non-commercial use."

In this case since the authors want srp to become a standard, its X11 type license is appropriate.

Re:Differences...

[altair1]

"I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also
states that srp is "free for both commercial and non-commercial use.""

Sorry, that's my mistake. Not sure why I thought it was GPLed. Thanks for the info.

Bwahahaha

[Phexro]

From the SRP page:
"The Project's primary purpose is to improve network security from the ground up - by integrating secure password authentication into widely-used protocols instead of adding security as an afterthought."

Re:If only I could SSH

[jeff_C]

I use PuTTY. a win32 ssh client and have found it works great. Supports color terminals, resizable windows, multiple connections, etc. Plus it's 1 file. No .dll's and it fits on a floppy.... Click here for the home page..... jeff_C

Audit it.

[generic]

Perhaps the maintainers would care to post something on bugtraq? announcing their new package.

Apples and oranges

[Djinh]

SRP seems to be an authentication protocol. A promising one, but just that, nothing more nothing less.

SSH on the other hand is a very useful application offering secure communications to another host. Keep in mind that SSH's password authentication happens after the encrypted channel has been set up. This means that the password can only be intercepted if the crypto fails.

SRP's security is based on similar cypro primitives as SSH's, so if the magic crypto hack we're all looking for gets found both will be useless.

Re:Apples and oranges

[Another MacHack]

SRP does rely on a shared secret (the password), but most of the time you already are going to have this set up. The advantage offered by SRP is that for a man in the middle attack to work, the host in the middle would have to either know your password or blindly authenticate you. SRP authenticates while passing information which is useless in identifying the password to someone without the shared secret.

Re:Apples and oranges

[tjw99]

SRP has applications that support it, most notably Telnet and FTP. SSH does encryption first, authentication second, but this is exactly the wrong order of steps. If the anonymous encryption is attacked (e.g. MITM), then the weak authentication underneath it is exposed. SRP, and anything that does ZK password authentication, does not have this vulnerability. BTW, SRP uses somewhat different crypto primitives than ssh's RSA authentication method. RSA is based on IF, while SRP and other D-H methods are based on DL.

Re:If only I could SSH

[Puff65535]

If you have an SSL web server(acually you don't need it, but you open yourself to attack if you use plain http)you can use a java ssh applet from MindBright I've been using this for about a year now and it has worked in most recent browsers. It makes life as an admin easy, now I don't have to hand out ssh clients for every OS under the sun, just an URL.

Sourceforge?

[|c0bra|]

This is really interesting since anyone hosted by SourceForge is required to use SSH and SCP to get to their shell accounts and transfer files. It would be nice to see the people producing SRP put it up on SourceForge if they haven't already. For those of you who dont know, sourceforge is a free service brought to you by your friends at VA Linux. Its for people who need a place to work and publish Open Source projects and stuff. I love it so far.

Re:SSH windoze client? Yes! Use TeraTerm. 3.1/9x/N

[slashdot-terminal]

Do a search for TeraTerm or TeraTermPro. Then get the add-on for ssh and the crypto (Blowfish, IDEA, RSA). No source for any of this, though. Binary only. But since it's for windows, how secure could it possible be at best? If
your machine is on the net, MS can probably read your keystrokes anyway.

secureCRT form for download

zow Which also provides for ssh

Re:If only I could SSH

[rnt]

The rare occasions I need to ssh from a windows machine I use PuTTY.

The main reason I like it is because it's just one .exe file. I always find when I'm in need of ssh there is no ssh-client installed on the machine I'm working on...
PuTTY doesn't waste my time with fancy installshields: you download it and you start it. That's it.

I must admit most of the time I'm working on unix machines, PuTTY is just to fill the gap... :-)

http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html

Re:telnet rulez

[vectro]

Erhm, actually, su -, unlike su generates a login shell, not just a regular subshell. This includes resetting your enviornment (as root) and chdiring to the /root directory. It's especially useful on systems where /sbin is only in root's path; with su -, you get /sbin in your path when you su.

Re:Telnet is the only solution.

[slashdot-terminal]

If you want to remotely admin a box using an insecure protocol, you're an idiot. Please come back when you have a clue.

I am just wondering if PCAnywhere (and other related NT admining tools) have encryption features comparable to ssh and friends?

SSH - the only secure solution... for now

[John Hurliman]

I would gladly use SRP... as soon as sourceforge.net uses it on it's servers... as soon as I can use it to log into my shell accounts and cvs repositories instead of SSH. Even if this technology is far superior to SSH, I won't use it until it becomes more standardized.

Re:SSH - the only secure solution... for now

[tjw99]

So how does one go about getting the world to use a better mousetrap? SRP is well-established as offering strong password security, yet I think most people are still using weak password authentication, either inside or outside ssh. This may become a moot point once ssh includes support for SRP authentication.

Re:If only I could SSH

[jeff_C]

Oops, dang alt tags are screwy....

fixed

SSH

[Anonymous Coward]

Surely IPSec is the way forward in the next few years. Encryption at the network level means that you can telnet, ftp, whatever without having to worry about the contents of your packets being intercepted and put to misuse (e.g. password gathering) ...

So if you run an ISP, or just a webserver, in a few years your 'lusers' will be able to put up their nifty HTML and links to their family and friends' websites without compromising your security ...

Although Win2k comes with IPSec, its not the most obvious of things to set up, so don't expect 'em to be using it right away! Hopefully a default configuration will come along in a few years and we will all be able to surf safely.

p.s. In the meantime, can anyone recommend some international software that I can install to secure my FTP connections? I don't live in America, so I am missing out on all the websites with "download my great secure software" with a .org extension in the URL, not mentioning where they are hosted, cos I don't want the FBI, NSA, or whatever you people have banging on my door one night! So tell me! p.s. I already use PuTTY.

Re:SSH

[dvdeug]

Don't worry about the FBI, NSA or any other American group.

(1) I believe that the resposibility is on the group, not you, to stop you from downloading it.

(2) To know you did it, the FBI/NSA/whoever would have to be monitoring internation communication. To come out and admit to it in the internation community (which is what they'd have to do) would garner more shit then it's worth.

(3) They really don't have the time or concern to deal with you, anymore than you'll get big trouble for an illegal copy of Windows.

PUTTY rocks!

[zosima]

It is free (only as in beer, but better than nothing), small, and stand-alone. That means there are no tied in dlls so you can just put it up on your webpage and pick 'open' so you can have a shell even on locked down windows boxes. Plus it does telnet sessions a lot nicer than windows telnet (yeah, I know, what doesn't) so it makes for a nice 2 in 1.

Re:PUTTY rocks!

[errorlog]

I agree Putty does rock. I work for a local isp, and there are times when i am onsite and i need to get into the server to ie... change a password, check how the clients connection looks from the server end, etc. Putty fits on a floppy, all I have to do is put it in the drive, do what I need, then I clean up the registry of anything putty puts in there when done (paranoid is better :).

********

I allow telnet in, but only as bait to nab h4x0rz

[Anonymous Coward]

I have a crippled dummy account set up which I openly telnet or ftp into occasionally. There's no write permission for ftp, the shell does nothing but return a fortune cookie and exit. I do however track all logins and login attempts. I use this account to lure the packet sniffers out of hiding and report them to their ISP. Come and get it boyz. heh heh.

Re:Encryption style

[drnomad]

Download link is here. You need to rename pfa.html to pfa.

Console run you must type ./pfa where is a product of two primes. Disclaimer is that is only works for signed 64-bit numbers only.

enjoy!

Comparing Apples to Oranges

[Joe_NoOne]

People I know use SSH to encrypt their connection. This is nothing but a replacement for RADIUS or TACACS - a means to encrypt your login but not your session.

Re:Comparing Apples to Oranges

[tjw99]

SRP Telnet/FTP encrypts the entire login session.

pcAnywhere encryption.

[Otto]

>I am just wondering if PCAnywhere (and other related NT admining tools) have encryption features comparable to ssh and friends?

pcAnywhere (version 8 at least) provides four types of encryption: Public Key encryption, Symmetric encryption, PcANYWHERE encryption, and No encryption.

The public-key is as good as Windows is. It uses the Microsoft CryptoAPI, and can do 128-bit is your Windows has 128 bit installed (say you installed 128-bit IE, for example).. I haven't set this up, but you need a certificate authority in order to do it, according to their helpfiles.

Symmetric: no information available. Presumably it doesn't send the symmetric key across, but maybe it does. If so, then it's pretty worthless. If not, then how does each side know what the key is? Got me.

pcAnywhere encryption: minimal encryption, according to their own helpfiles. Probably something really simple and easily broken.

None: None, obviously.

Just a little FYI..
---

Re:telnet rulez

[scumdamn]

That's the most informative post I've ever seen on Slashdot. I thought there was no other way to to this that to log on locally as root. Thanks.

By the way, I was not being sarcastic at all. Seriously.

Re:telnet rulez

[Fluffy the Cat]

Maybe there's nothing that you care about on the machine. I had a thought I don't know about you but perhaps if you security gets compromised and someone was doing one of these fabled attacks then perhaps you could just shut down the machine or turn it off in the first place?

If a single machine on a network is compromised, the entire network's security is greatly decreased. If someone cracks my machine, 600 other machines become hugely more vulnerable because the first thing any even vaguely competent script-kiddie is going to do is install a packet sniffer. As for turning machines off if they start being used for DoS attacks - great. I'm sure the remote site will be thrilled that it only took a few hours for you to wake up/get home/notice before pulling the plug. Security is not something that should be dealt with half-heartedly, and if you're not going to care about security then your machine should not be allowed anywhere near the internet.

Who transfers to the root partition as part of their normal access or for su'ing?

That's what su - does.

Assuming you edit the file /etc/login.access or something like that you could just remove logins for root or anyone else from certain times. Bango you have removed the problem without expending any problems at all.

You mean block root access at certain times of day? But that would prevent me from doing remote administration at certain times of day, and still does nothing to prevent someone packet sniffing my root password when I do use it. From that point on, I've lost. You should never transmit your root password via telnet unless you trust all the other hosts on your network.

Magical Factoring of Primes: SNAKE OIL ALERT

[rambone]

Firstly, I doubt completely your claim to be able to factor primes fast enough to be useful in hacking the recommended encryption in SSH.

Secondly, if you followed security lists at all, you'd know that encryption attacks are the least succesful way to hack a security tool.

Convienience (sp?)

[tsphere]

I'm not sure if anyone's mentioned it, but my favorite use for ssh's arbitrary port forwarding is setting up secure X connections. It's a fast, easy, secure way to use all my cool graphical applications while diddling away on the SPARCs in lab. It's also the easiest way I can find to get remote X sessions to tunnel through a masquerading firewall.

The punchline: When srp can automatically do secure X, it'll be ready to replace ssh.

Re:If only I could SSH

[mystik]

putty is nice.
Simple, doesn't do port forwarding, just does ssh-terminal connections interface is brain dead, Source available, and it' only a ~210k binary (unextracted- run it right from the floppy)
http://www.chiark.greenend.org.uk/~sgtatham/putty. html

Re:If only I could SSH

[ragnar]

The plug in for tera term is here.

Re:If only I could SSH --- You can

[Fluffy the Cat]

PuTTY is great. It's open source, works well and includes an SCP client so you don't have to use FTP to transfer files and send your password unencrypted anyway. Did I mention how great it is?

Re:PKI and other issues, Interlock protocol

[stain ain]

There's a way to defeat, in some extent, man in the middle attacks when using public key cryptography: the interlock protocol designed by Rivest and Shamir.

The protocol works this way:
1) A sends B his public key
2) B sends A his public key
3) A encrypts using B's public key and sends half the message to B
4) B encrypts using A's public key and sends half the message to B
5) A sends the other half to B
6) B sends the other half to A
7) Both A and B put the two halves together and decrypt the message with their private keys

If someone is in the middle, he can change the public keys by its own keys, but then in points 3 and 4 he will not be able to pass the real message because it has not been transmitted yet; he will have to invent a completely new message and though the "conversation" will be completely different. This is not a perfect solution since, in fact, he will be able to intercept at least the first messages exchange, but his presence would be detected quickly.
As you pointed, the good solution is to use some kind of trusted third party authentication.

Windows Clients

[Joe_NoOne]

Is there a way to encrypt a windows net drive connect to a samba client? I know ssh and variants allow secure telnet and ftp sessions, but what about secure drive mounting (both windows and nfs)?

Re:Telnet is the only solution.

[Anonymous Coward]

telnet is fine as a tool, but telnetd is banned forever in my domain...

SRP plus CIPE

[rjamestaylor]

it seems to me that SRP only offers secure password transmission and forgoes on packet encryption

We've used telnet over the Internet for over two years as our initial ASP offering (we're readying our web-based application to replace it). That is, we're able to deliver our *nix based enterprise application over the Internet via telnet (as long as we have a maximmum latency of 500 ms, that is). These issues of securing login and packet data had to be addressed for us to convince our Fortune 500 customers to buy into our Internet-based solution.

Combining SRP, for password transmission, and CIPE for complete packet encryption, we're able to provide a reliably secure telnet session.

If we didn't have SRP and CIPE, we'd be SOL.

P.S. At the project's inception in 1996 we could not cost-justify any solution that required a per-user license fee. This threw us into Open Source solutions (and the ability to hack at the source code has proven a marvellous benefit since then).

:-only kona in my cup-:
:-robert taylor-:

Re: hmm

[drnomad]

It would be so kind of you to calm down.

First of all, I'm absolutely no security expert, the only thing I know is that finding large primes is very hard. So this part of the whole thing kept me busy, I posted it here to get some reactions, maybe some ideas.

Secondly, the binary I posted is not factoring primes, it does a numerical determination, so it won't find them right away, it must search.

Althoug it searches, this searching is done very fast.

Thirdly, I don't care what critics say, as I'll be working on this program to get it even faster, and I will support larger integers in future. I just hope somebody enjoys it.

Once again, name a major hack due to SSH flaws

[rambone]

All you've pointed me to are the usual rootshell alerts put out by the author of SSH himself - a process which is healthy and beneficial to SSH users.

I never denied that SSH suffers occasional buffer overflows - like I said - they get fixed.

SRP has a tiny userbase- you should assume that it also has an equal number of issues waiting to be discovered anf fixed.

Your only other alternatives are telnet/rsh or take your box off the web.

Given those choices, I'll stick with SSH.

Re:Once again, name a major hack due to SSH flaws

[GoNINzo]

Hrm.

Having my box compromised due to someone evading tcp wrappers, or talking unencrypted.

One way, my box is hacked. The other, someone *might* be able to snoop me, assuming they have some node between myself and my box.

--
Gonzo Granzeau

Re:Once again, name a major hack due to SSH flaws

[rambone]

Having my box compromised due to someone evading tcp wrappers, or talking unencrypted.

These aren't SSH-specific issues, these are issues of your users not using tools as they should. Installing SRP isn't going to make them more courteous.

The other, someone *might* be able to snoop me, assuming they have some node between myself and my box.If you can't secure your physical network, software based security is irrelevant. I think you're reaching at straws.

Re:Once again, name a major hack due to SSH flaws

[GoNINzo]

What part of 'I was hit with [a security issue with ssh]' don't you understand?

Someone breached my network because of ssh. How 'secure' is that? It should be a solution, not the problem.

unencrypted telnet? I'll admit it's not the safest thing in the world, but I don't have a false sense of security, and I havn't had someone break in since sshd was removed.

Of course, I'll point out that this was all ssh1, not ssh2.

--
Gonzo Granzeau

Re:Once again, name a major hack due to SSH flaws

[gellor]

Well...

It all comes down to what you consider vital services. A machine with NO remote services enabled is ALOT more secure than one with even just telnetd/sshd. Not very useful perhaps but safer.

Your choice was for less security on remotly accessed data and more local security (I need to issue a cavet here that you may, in fact, compromise local security more if you EVER su up from remote). I personally perfer to know that, barring man in the middle attacks (and at the point when you are trying to protect yourself from enities capable of hijacking/usurping your connectivity you have some other pretty big problems to deal with), my remote communications back to my machine are hidden from prying eyes. The price I pay for that is keeping up on the latest SSHD problems and patching to fix them and I'm ok with that.

--
Gellor

Re:Once again, name a major hack due to SSH flaws

[Pathwalker]

I had a system at home broken into through the recent attack technique involving bugs in RSAREF. Little buggers did an rm -rf /* when they realized it was a 486. Saved me the trouble - I was going to wipe and reinstall it in a couple of days anyway :-)

Re:Once again, name a major hack due to SSH flaws

[tjw99]

Keep in mind that although SRP has a small (but rapidly growing) installed base, it is *cryptographically* more secure than SSH with password authentication. While SSH has had buffer overflows, this is not particularly relevant. SRP addresses design flaws and shortcomings in the SSH protocol and can in fact be added to SSH as an authentication mechanism.

Re:USe OpenSSH

[jpatokal]

I wouldn't trust an SSH binary I didn't compile myself, particularly from an american company the NSA allows to exist.

You don't have to -- SSH happens to be from Finland. <grin>

ObURL: http://www.ssh.com/about/company/

Cheers,
-j.

Re:Encryption style

[drnomad]

At the moment, I don't have a clue how fast it is, it broke 16-bit prime codes in less than 0.64 seconds, I don't know whether this is fast.

It doesn't use much memory (i.e. I think less than 4k)

I'll won't post the source code as I think I'm on to something (and maybe it fails in the end, you never know), if I do succeed, I'll be taking all credits for it.

I'm still doing all sorts of mathematical research to get the program faster, so complexity is growing.

At the moment, complexity is quite low (well it is for me anyway), but it's hard to explain the principle to somebody else (and boy, I tried!)

Re:Telnet is the only solution.

[TheCarp]

> Also each and every public type machine that I
> have ever used and all unix machines
> I have never used have never either made ssh
> avaible or it was not really practal. SSH is
> only useful if you regularly connect to remote
> unix machines that support it or you have
> multiple machines with shell access.

Well yes of course... ssh is only useful when
connecting to a host that has sshd installed.

Personally, here at work, ALL of our machines
use ssh. Also, any machine that is mine to
administer as I see fit, doesn't even support
telnet...I turn it off.

I think anyone who runs a unix server should
install ssh, and encourage all users to use it.
In fact, wherever even remotely feasable...telnet
should be turned off.

ssh is too easy to use to not support. plaintext
passwords are too easy to sniff to allow.

(I should note that we recently had a user acount
compromised, which we believe was the result of
a password sniff when one of our users was out
of the country and telnet'd in internationally)

-Steve

Re:USe OpenSSH

[erice]

OpenSSH is a pain in the ass to build/install on many systems especialy those, like Solaris, that have no /dev/random. I have it working at home but there's no way I'm going to install it on all the machines at work.

And, BTW, ssh comes in source form.

Re:Telnet is the only solution.

[EXTomar]

As well a firewall shouldn't. The firewall itself has to understand how SSH works. No firewall should just blindly redirect connections. :-) Or is that not what you mean?

Seriously, for machine to machine connection, both of which have SSH clients and servers on them, it works great.

Re:USA: Pure, concentrated right-wing evil insanit

[TheCarp]

I know this is a troll...however...I just need
to correct the glaring error...

> SSH is an American product. Don't touch it. It's
> bound to be of wretchedly poor quality, because
> US workers are wage slaves with no personal or
> civil rights, and slaves always do lousy work.

Well most of that is somewhat true...no civil
rights, wage slaves (often)...low quality work...
yup that too sometimes...

However... the person you reply to was talking
about OpenSSH. A free software product, which
was developed in Canada, not the US.

> Ever heard of the Greater Fool Theory?
> Capitalism is the Greater Fool Economy. Don't
> be the fool.

I suspect you don't actually believe this.
However, here I have to agree with you...
Capitalism is a pretty pitiful system (though
most people don't understand the beauty of
the alternatives).

Which of course has nothing to do with the topic.
Especially considering OpenSSH exists and was
not (AFAIK) written with capitalist goals in
mind.

Re:Telnet is the only solution.

[The Mayor]

BackOrifice provides a secure method of remotely administering a Windows-based PC. It's free, too.

-dan

Re:If only I could SSH

[ripicheep]

I too use tera term pro with the ssh add on and it's great. the only problem I find with it is I can't use the ^c ^v cut and paste, you have to use the menus, but that's a minor quibble. Overall I find ttermpro to be very useful.

Re:PKI and other issues, Interlock protocol

[fizzz]

The algorithm you're suggesting is mostly a precursor of the current PKIs (I haven't read its reference paper, and don't really have the time to find it, but I wouldn't be surprised to find that it dates back ~RSA publication times).

By definition, at it's worst, a man-in-the-middle attack cannot be blocked/prevented: if A has never met B, there is no way for A to be convinced that she is really talking to B and not to C. If B is in the same situation (having never met A) and is also really speaking with C then although their communication may get from one to the other, it will always be possible for C to see all of it (since C can simply pretend to each of them to be the other player and then decrypt/reencrypt the message).

For trust to be achieved perfectly you will always need an additional piece of information (or mean of identification) in which you can trust... PKI's are one of the possible solutions. In the case of the Rivest-Shamir you're describing both parties must have common knowledge of the message's content prior to starting the algorithm otherwise a middleman could switch messages for it's own. In essence the protocol becomes dependant on the messages's nature and the fact that both players must know it... Two complete strangers could not use it.

But then again, there can't exist a protocol for two complete strangers to identify themselves to one another...

Re:Telnet is the only solution.

[AnOminous CowHerd]

The firewall is a separate issue. I think the original poster is talking about ssh port forwarding which is very handy indeed:

ssh -L 1234:somehost.com:21 somehost.com tail -f /etc/motd

then

ftp localhost 1234

Voila! Instant secure ftp connection to somehost.com. (passive only). This is a silly example, but it's very handy for Windows boxes that might not have scp.

Re:Encryption style

[toastyman]

Perhaps I'm just in a bad mood today, but debunking this sounds fun.

First, the code you posted below, apparently never outputs anything but:

f1 :
f2 :
not a good cypher
cancelled
way :
pfa 0.1 by Frank Joppe (C) Copyright 2000
Usage:
pfa
pfa
--x Hexadecimal input, use lowercase only!
--help This screen
help

from a look at the binary. I'm not quite silly enough to try to run it, but I'm sure someone here on a scratch box will.

Secondly... Define fast? Faster than, say, http://www.entropia.net/prime? They're using a massive distributed effort to factor prime numbers, and it still takes a serious amount of time.

My PIII 600 takes a few weeks to look for factors of (2^8858987)-1 using Lucas-Lehmer's algorithm. If you've got something that can top this, I'm sure a lot of people would like to know....

People like The EFF especially, who is offering up to $250,000 for large prime numbers.

How about some benchmarks, or some documentation on how it works? Or why you're using geocities to distribute it?

- Kevin

Re:Telnet is the only solution.

[guacamole]

Your post is totally off subject. You can use telnet -application- to acconect to any TCP port. When people say telnet is insecure the refer to the telnet -protocol-. You can even use telnet program to connect to the -ssh- port on some host and conduct all your transactions in a secure way if you could just encrypt and decrypt all the data in your head. No one is saying that the application should go away, but people who know about ssh and still use telnet for remote logins should be shot.

Re:Encryption style

[QuMa]

The link's broken. Do you by any chance mean GIMPS?

Value added for SRP?

[srussell]

As far as I can see, SRP provides no functionality that isn't already present in SSH. In the interest of full disclosure, I'll state that I don't have anything to do with any SSH project, although I do use OpenSSH. When I speak of SSH below, I'm speaking of OpenSSH in particular.

From a purely technical point of view, SSH, when using public key cryptography, is as secure as SRP. In the following list, I don't claim that SRP doesn't do any of these things; I'm merely clarifying what SSH does do.

1. SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
2. SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
3. Authentication is done either with public/private keys or with a server side authentication mechanism, such as PAM. In the second case, any passwords or other information is transmitted encrypted, and so is secure. In the first case, the password is never transmitted and there is no chance of the user's password on the server being compromised through SSH. The user's password is never used to encrypt a session.
4. OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
5. SSH allows securing of arbitrary ports, and provides extensive port forwarding capabilities. Therefore, any service on a server running SSHD can be secured, as long as the client program can alter the port of the service it is requesting. As an example, to secure an IMAP connection, one would issue: ssh -L 1442:servername:143 servername and then connect with their email client to localhost:1442.
6. Although most users of OpenSSH are unaware of the fact, OpenSSL, which is required for OpenSSH, provides a powerful tool for dealing with X.509 certificates. With OpenSSL, you can encrypt, generate hashes, generate certificates, generate certificate requests, and perform a large number of other security-related actions. OpenSSL documentation is extremely sparce, and due to the complexity of X.509, using OpenSSL tools can be difficult; this is probably the primary reason why most people are oblivious to OpenSSL capabilities.
7. OpenSSL is the basis for a number of port wrapping tools, such as sslwrap. With these tools, you can provide secure sockets to services such as HTTP, IMAP, telnet, and POP. Many clients, such as Netscape, understand secure sockets, and several ports are defined as "well known ports" for these secure services. (EG: IMAP's secure port is 993, and Netscape Communicator knows and can take advantage of this).
8. Using public keys with SSH simplifies accessing services, so that 'ssh' and 'scp' are as easy to use as 'rsh' and 'rcp'. This is slightly less secure on a shared client, because the private key is held in the client memory during a login session, and is subject to core dump attacks. If the client machine is not shared, this is not an issue.
9. OpenSS[HL] doesn't require using RSA algorithms; in fact, you can choose from any number of non-commercial algorithms.

The SRP site claims that there are several "advantages" to using SRP, but never says what these advantages are in relation to. In particular, the SRP site does not claim that SRP is more secure than SSH. SRP is certainly more secure that vanilla telnet, but I see no advantage to using SRP over SSH. The obvious advantage to using SSH over SRP is that SSH is ubiquitous, and well tested.

Please, if anyone knows any way in which SRP is superior to SSH, I'd like to know.

Re:Value added for SRP?

[kkenn]

OpenSSH, last time I checked, only implements the SSH version 1 protocol, which only supports RSA. There's no way to make it use an unencumbered PK algorithm without breaking compatability with all of the other SSH 1.x implementations out there.

The SSH 1.x protocol also has a design flaw which allows insertion of arbitrary data into the data stream, because (I believe) it uses a weak CRC checksum instead of a strong cryptographic hash to verify the data integrity. Again, fixing this would break interoperability with other SSH implementations.

The SSH v2 protocol _does_ support other forms of authentication (and strong integrity protection), I believe, but it probably would require a major rewrite to implement, and that hasnt happened yet.

If you're in the U.S. then unless you can legally use RSAREF you're SOL for OpenSSH :-(

Re:Value added for SRP?

[srussell]

Mmmm. You are right; you can change cyphers, but not public key algorithms.
<p>
Of course, this will all be moot in September, when the RSA patent expires...

Re:Value added for SRP?

[kkenn]

Yes, they are DETECTED, but not PREVENTED (the "official" SSH does this too). If I know someone has inserted data into my session, how much use it after they've already done the damage?

The comment about RSA was in response to someone else who claimed OpenSSH removed the limitation on RSA, which it doesn't. I was careful to point out that *NO* conforming SSH v1 implementation can work without RSA because it's a fundamental part of the protocol.

Re:Value added for SRP?

[tjw99]

In a sense, you are correct when you say that SSH when used with RSA authentication offers the same level of security as SRP. The big value-add is that SRP doesn't require you to keep an RSA key - it derives its security using only a password. You can sit down at any remote location, knowing only your password, and log in. At the same time, the session is fully protected against both active and passive attacks.

SRP is more secure than SSH+regular passwords.

SRP is more convenient than SSH+RSA authentication.

SRP can be integrated as an authentication mechanism for SSH (and it has, check out LSH).

Re:Value added for SRP?

[Furry Ice]

SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.

This can be thwarted with a man-in-the-middle attack when the known hosts file is created.

SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.

Here's one where there is some value-add to SRP. In this case, both create session keys which, if cracked, cannot be used to crack other sessions. However, if the private keys to an SSH connection are leaked, then _all_ sessions can be immediately cracked. With SRP, even if the secret (a password) is known to an attacker, he can't crack sessions. He would be able to successfully authenticate himself, however. One thing I've never been sure of is what's actually stored in an SSH private key file. Is it the key itself, or an encrypted form of the key, which is decrypted with your passphrase? If so, then SSH keys do have some protection in the event of a system compromise. SRP does not store passwords on the system in cleartext, just verifiers. If the verifier file is compromised, then an (expensive) dictionary attack on it is possible. This is the only known way to employ a dictionary attack against SRP.

One difference between SRP and SSH (which I would call an advantage, some may call a disadvantage) is that SRP requires only an SRP enabled server and client to operate. If you know your password, you will authenticate successfully. With SSH, this will work if you have password authentication enabled, so that the two hosts authenticate each other, negotiate a symmetric key, and encrypt the password. As mentioned above, if those servers' keys are ever compromised, your password will be revealed to the attacker. To make SSH more secure you need to create your own keys on every machine you use, and copy the public key to the machines you wish to access. If the hosts you wish to access don't allow password authentication, then you can only access them from the particular computers you've explicitly allowed access from. This can be very inconvenient, especially when you work with many computers. In this case, I have to say I prefer SRP. One password works from anywhere with perfect forward secrecy.

Re:Value added for SRP?

[tjw99]

SRP is listed as a "planned feature" of LSH. Look for it in the next release.

Re:Telnet is the only solution.

[jgerman]

Actually we as a country all sacrifice liberty for security. Do you have locks on your doors. Passwords into your computers? I thought so. Any company is going to use the most secure option available. That's just a fact of living in a capitalistic country. BTW throwing quotes around like that defintitely makes me question the validity of you being in Guiness. And another thing, Fermant's last theorem HAS been proven.

Darn 'anonymous' button

[That Nebulous Entity]

The comment above that shares the below disclaimer is actually from me. What I get for playing with the anonymous button... sigh. Disclaimer: The author has been known to be wrong before, and will probably be wrong again some time in the future. The author is also non-deterministic. Deal with it.

Re: hmm

[Dr. Blue]

First of all, I'm absolutely no security expert, the only thing I know is that finding large primes is very hard.

No, you're wrong. Finding large primes is quite easy. If it weren't, we'd have an awful hard time doing many of the current encryption algorithms.

What's hard is factoring large composite numbers that are the product of two large primes.

It's not clear what you're saying your program does: does it factor numbers, or is it a program that searches for prime numbers? It would be pretty hard to believe that you've got anything efficient for the first, and the second is just not too hard to do (although to be blunt it doesn't sound like you know enough math to make something efficient for this one either...).

Re:Telnet is the only solution.

[evilpenguin]

Huh, I say, Huh?!?

When you telnet to a specific port you are just connecting a socket to it and passing stdin to it and passing what comes out of it to stdout. If you had to write this from scratch it would be about 150 lines of C code (and many fewer lines of perl or Java code). You aren't "sacrificing telnet" to use ssh!

The rest of telnet is support for terminal emulation and some terminal capabilties negotiation at start up, all of which works only when talking to telnetd, and none of which comes into play when connecting to any other port (unless, of course, you're connecting to telnetd on another port).

A later poster complains that ssh is only useful for shell accounts. Absurd. You can do arbitrary port forwarding through ssh, turning ANY network service into an encrypted service. It is a VERY handy way to create a secure opening through a firewall:

Machine A is behind a firewall that forbids incoming connections.
Machine B is out on the internet.

You want to use a service on machine A from machine C (another machine out on the internet).

Machine A can make an outbound ssh connection to machine B and tell machine B to open port 3500 on B for listen and to "tunnel" it to port 80 on machine A.

Machine C can then type this URL into his browser:

http://[machine B's address]:3500/

This will connect to port 3500 on machine B (obviously), but less obvious is that machine B will forward all traffic encrypted over the SAME ssh socket Machine A has open to B. No one observing the traffic between A and B will know that machine C sent traffic to machine A, nor will they be able to tell that more than one "conversation" is taking place over the single link.

SSH is not sacrificing freedom, it is enabling freedom. No, I won't use SSH2 (which is a close commercial product), but I certainly will use SSH1 and OpenSSH.

SSH is a major tool for flexibility,

Re:Telnet is the only solution.

[Zurk]

rsync can transfer files over encrypted ssh connections. (http://rsync.samba.org)...an NFS would be too slow..however secure NFS (via secure ports) has been developed and is available for linux..its included in my distro (redhat).

Re:Telnet is the only solution.

[PieceMaker]

That's just a fact of living in a capitalistic country.

No, it is a fact of living in ANY human society in which man's life is not valued. Therefore, it is a fact of life in socialist, communist, fascist, dictatorships, theocracies, and in the U.S., which is in fact a mixed economy -- not a true capitalistic country. In fact, of all these, capitalism is the only one that comes close to respecting men's lives and their rights to control their lives and their work.
--

Seems vulnerable to spoof atack

[argoff]

I could block serverxyz from the network, rename my server to serverxyz and be able to do a spoof because there are no pre-defined keys that could be authenticated otherwise to show that I'm not.

Re:Seems vulnerable to spoof atack

[tjw99]

If you analyze the protocol, you'll find that if your spoof server doesn't have the user's verifier, the protocol will detect this and fail. Furthermore, your spoof server will be unable to mount even a *dictionary attack* against the password even under this circumstance. This is not true of SSH with ordinary password authentication.

SSH for Teraterm: TTSSH

[Robin Hood]

There's an SSH module available for Tera Term someplace.

You're thinking of TTSSH. When I have to use a random Windows box and I need SSH, this is what I download and use.
-----
The real meaning of the GNU GPL:

Apples and Oranges

[Anonymous Coward]

Stanford's biggest complaint about SSH is a political one. Their point is *IF* you can't politically use encryption then SSH buys you nothing hence SRP is preferable. However, if you take the time to use SSH then you probably are able to use encryption. SRP does not provide an alternative to SSH with encryption, it provides an alternative to authenticating on an insecure transport. When compared with other similar protocols such as APOP, SRP has definate advantages. Despite these advantages, present implimentations do not address everything that SSH (with encryption) is designed to provide:

• 1) Keeping the initial authentication information secret
• 2) Authenticating future packets come from same client that authenticated
• 3) Keeping the entire session private

SRP does the first step of keeping the initial authentication secret. Since both sides then have a secret random number as a side effect of SRP, it would be possible to use a collision resistent one-way hash to "sign" future packets. However, as far as I can tell, no implimentation of SRP currently accomplish signing of future packets. The last point can't be addressed while still meeting SRP's goals of not using encryption. This becomes a problem when legacy authenitication methods are used withen the SRP authenticated session. For example, withen an SSH encrypted stream, the "su" application can be run without revealing the password in clear text and without the application needing to be altered. SRP on the other hand only can address this if your willing to replace the "su" application and all other authentication applications to be used withen the session (passwd, DBA tools, etc.) via SRP based ones. In some cases, such as with database tools, an SRP replacement may not be possible. Therefore, SRP has it's own political problem of: is all your authentication application vendors accepting enough of SRP to provide you with an SRP aware version of their application? You may find that depending on what country you live in, the politics of SRP acceptence is far worse problem then the politics behind encryption.

That all having been said, I am impressed by SRP and would like to see it submitted to the W3C for use in future revisions in the HTTP standard. There are several cases that I'm aware of that keeping the password private is important but the data isn't sensative enough to warrent the overhead of SSL.

Advantages to SRP

[kkenn]

The main advantage to SRP is that it uses a simple password to authenticate, instead of requiring the user to carry around a public/private keypair with them as they move around (in other words, there's no client-side setup required beyond the installation of an SRP-capable client app). This can be the same password as the regular UNIX account password, although it's hashed in a different format and so SRP can't be used with existing password files. I've written a plugin crypt module for a replacement to FreeBSD's libcrypt which teaches crypt() how to speak SRP hashed passwords, so if you do something like this then everything else (non-SRP apps like login) will authenticate just fine. There's also an SRP PAM module floating around.

Security-wise, the authentication protocol has been well investigated, and as far as I know it's stood up fine so far - no serious weaknesses have been discovered.

On the other hand, the SSH v1 protocol as implemented by OpenSSH and all other SSH v1 implementations has an insertion attack which allows the insertion of data into the stream because of insecure integrity protection (it uses a weak checksum). The SSH2 protocol fixes the design flaws in SSH1 (as well as allowing other key exchange schemes than RSA) but OpenSSH doesn't speak it (since it's based on an old SSH 1.x distribution). Hopefully this will change in the near future.

As part of the SRP authentication handshake, a session key can be shared which allows the rest of the session to be encrypted. So SRP provides for authentication as well as secrecy, like SSH does.

SRP is just an algorithm - there's nothing preventing someone from creating a SSH-like app which authenticates using SRP, and then provides all of the port-forwarding features which SSH does. This would be quite useful, actually, and is something I'm hoping to do when I get around to bringing native SRP capability into FreeBSD.

The major downside to SRP is that the authentication is only as strong as your passphrase. But on the other hand, this is true as well in SSH if you can get a hold of someone's encrypted private key (if they carry it around with them on a floppy so they can log in from random hosts, for example). This can be mitigated by enforcing strong passphrase selection on the SRP server. An attacker sniffing the authentication exchange cannot obtain any data which is useful for determining the passphrase, even by a brute-force dictionary attack - you have to obtain access to the /etc/tpasswd file and brute-force attack that.

The Stanford SRP distribution is distributed under a BSD-style license. This is good for most people (e.g. commercial users who want to add SRP support to their products, etc), but it may prohibit the code from being incorporated into a larger GPLed program (because of the GPL's "no other restrictions" clause and the BSDL's "must give acknowledgement" clause). Consult your lawyer..

On the whole, SRP is more practical to implement because it doesn't require per-user client-side configuration. In most ways it seems to be a superior solution which is just awaiting wider adoption.

Re:Advantages to SRP

[srussell]

There are certain advantages to not requiring a public/private key pair to be lugged around, but also certain disadvantages.

Most importantly, you imply that public/private key authentication is the only way to use SSH, and this is not true. SSH (OpenSSH) allows users to authenticate from arbitrary hosts securely through the normal PAM authentication, so I still don't see the advantage of SRP. Still, if you allow this sort of authentication, SSH becomes less secure, for reasons which I outline below.

The downside of using a passphrase as the authentication mechanism is that it is inherantly weaker than using public/private keys. If a private key is stored encrypted, the system is more secure by nature of requiring both physical access to the private key, and access to the passphrase by which it is encrypted. If you are using a passphrase authentication mechanism and I somehow get your passphrase, you are screwed; I have access to all systems where you use that passphrase. However, if you somehow get my passphrase, and I'm using public/private keys, you *still* have to somehow get ahold of my private key to authenticate yourself as me. Similarly, just grabbing my encrypted private key isn't enough, because you can't decrypt and use the key without my passphrase.

OpenSSH does solve the SSH1 protocol security issues. Check their website.

SRP hasn't been around nearly as long as SSH, and hasn't been as severely scrutinized for weaknesses, so it doesn't mean much to say that no weaknesses have yet been found. Only time will tell.

Re:Advantages to SRP

[kkenn]

Can you point me to an exact URL? I could not see where they refer to fixing the insertion attack. Because this weakness is fundamental to the SSH protocol (use of CRC checksums) I don't see how they could fix it without breaking interoperability with other SSH implementations. This has come up a few times on the mailing lists..

I agree with your comments about encrypted RSA keys.

Something Stinks...

[pastaman]

Every point that the person who was comparing SSH v. SRP made was completely wrong. I can't speak for every implementation of SSH, but we only need one, OpenSSH. Sure, if you don't really care about security, you can use password authentication instead of using a key. That key can not only be an RSA key, but also a blowfish key or a TIS or others... Personally, i prefer blowfish.

Now, is forcing someone to *only* allow logins when using a key really solving any problem? If you need to get in to your box from somewhere and you don't have time to do so otherwise, then login using password. If you have something so secure on your box that password is not acceptable (your paraniod and should never use ecom either 8-}) then just configure sshd so that it doesn't allow password logins.

Besides, in most systems, the cyrpto that you use for remote administration is surely the least of your worries. Why not switch to OpenBSD so that you can sleep at night?

OpenBSD: Secure by Default... Ships with SSH

here are the links

[Jesus Christ]

It's not complete, and it's not meant to be.

Maybe this will help make it more so: homepages for some of the software you discuss.

• OpenSSH - http://www.openssh.com/
• [Commercial] SSH - http://www.ssh.com/
• Kerberos Network Authentication - http://web.mit.edu/kerberos/www/
• ENskip - http://www.tik.ee.ethz.ch/~skip/
• Linux FreeS/WAN - http://www.xs4all.nl/~freeswan/

Anyone interested in the software mentioned above, or even just general UNIX security, would do good do take a gander at OpenBSD (http://www.openbsd.org). It's based on 4.4 BSD, like most of the Freenixes, and is designed with security foremost in mind. Think of it as FreeBSD after reading "1984". ;-)

It comes with OpenSSH. And Kerberos.

Ooh, and also... stickers! Put them on your box, and maybe the MiBs that break into your house while you're at work won't even bother trying to crack yer system.

Remember: paranoia is good. Anyone with doubts regarding the truth of that statement should check out the Echelon links that have been appearing here lately.

Ciao.

I am the Lord.

Re:Telnet is the only solution.

[The Mayor]

I was being quite serious. BackOrifice is a more secure way of remote administering a machine than PCAnywhere, if only because it is open source.

Security through obscurity is not security at all.

two-party vs. three-party authentication

[coyote-san]

Any list, no matter how short, should include a reference to two-party vs. three-party authentication.

SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.

Kerberos, digital-certificates and some government sponsored systems use three-party authentication. This puts some limitations on your use, but these are generally reasonable restrictions if you think about it. (E.g., do you really want John Cracker to be able to remote mount your files?) Third-party authentication got a bad rep after some clumsy government posturing with the clipper chip, but it seems that a lot of people lost track of the many places where it's appropriate.

Re:two-party vs. three-party authentication

[dmiller]

SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.

Both SSH and IPsec also include mechanisms for prevention of MITM attacks. SSH uses RSA host keys which can be pre-exchanged (OpenSSH extends this to include PGP-style key fingerprints), IPsec can use a variety of methods including preshared symmetric or PK keys or certificates for various forms (OpenPGP, X509, DNSSEC).

Re: Kerberos

[coyote-san]

Kerberos is also available for both Red Hat and Debian. Debian has at least three implementations - two European implementations are on non-US, and I've packaged MIT Kerberos 5. (Still no word on when MIT will drop the export nag page, unfortunately.)

OpenSSH is still an excellent choice, but not because it alone supports Kerberos.

Re:SSHD everywhere?

[TheCarp]

> So, why can't I get my university to install SSH
>clients on all the desktops that we use to
> connect to our unix servers?

If the desktops are unix boxen...then they
should get their asses in gear and install
openssh (IMHO)
however...for Windows boxes...licencing can be
expensive. Here we have a SecureCRT licence pool
and ar eletting students and faculty get copies...
I have no idea what its costing the
University though.

Hopefully someday telnet will fall into disuse and
we can stop supporting it.

A metacomment

[Tr011Thr4$h3r]

Note to everyone: People, please don't make references to the "comment above" or derivatives thereof. There are many different modes for showing comments, such as Threaded, Nested, Flat, etc.

They can be sorted Newest First, Oldest First, or Highest Scores first. There are different levels you can set before it spills into index mode. You can change the threshold from -1 to 5. You can have different thresholds for replies. And it goes on and on. Besides, posts accumulate quickly - even with the same settings, it may not be "the one above" if you wait too long before hitting "submit".

So please, if you're going to refer to a post, and it's not one you're replying to, it helps to give the post's ID. That makes things much easier to follow.

Thanks.

Re:A metacomment

[Bald Wookie]

Who moderated the comment above? It is obviously offtopic :)

How do I count processes, it just says that I have 38911 basic bytes free...

-BW

Re:If only I could SSH

[wts]

The program i use that is quite nice is puTTY. It does telnet and ssh connections, and has a windows secure copy available called pscp that i use instead of ftp all the time.. i'm not sure what the web site address is, but i know if you search for "putty ssh"o an altavista you'll find it.

Mac SSH client

[paulschreiber]

There's an SSH version of NiftyTelnet that's really nice. You can't use it in the US, though, due to greedy patent nonsense.

Re:If only I could SSH

[Garpenlov]

I too use tera term pro with the ssh add on and it's great. the only problem I find with it is I can't use the ^c ^v cut and paste, you have to use the menus, but that's a minor quibble

Strangely enough, the Cut and Paste shortcut keys in Tera Term are... Alt-C, and Alt-V. Can be kind of confusing when you're switching back and forth cutting and pasting..

And for those of you who really don't speak German

[T-Punkt]

This is actually a German translation of this article made with babelfish.altavista.com.

Trolls aren't very creative these day I must say.
What do we get next?

`strings netscape.core`?
`fortune -a -m .`?

SSH vs SRP

[Aaron Denney]

SSH is both a protocol and a decent implementation of that protocol that is easy to deploy.

SRP is a protocol, but implementing it is a pain in the ass. You need special versions of login, telnetd, su, and whatever else does authentication. PAM modules fix some of these problems though.

As far as authentication protocols go, SRP is much nicer than ssh because in addition to authenticating the user to the computer, it authenticates the computer to the user. The SSH implementation does have some resistance to man-in-the-middle attacks, by keeping a cache of known host keys, but this doesn't help much the first time you connect. SRP lets you verify that computer you connect to does indeed have an account with your name and password, it doesn't allow man-in-the-middle attacks.

SRP also has this nice session key lying around afterwards that lets you encrypt, but I know of no programs that actually use it.

Re:SSH vs SRP

[tjw99]

PAM modules are the preferred way to set up EPS/SRP on systems that support PAM. Then, it becomes no more difficult than supporting, say, MD5 passwords, and substantially more secure.

SRP Telnet and FTP encrypt the entire session, btw.

Crack my machine !

[jfwcc]

-
Interesting, that so many folks believe in telnet.
I thought I was the only one.

Now I would like to test my configuration, because I think it's bulletproof.

There is no encryption, no nothing. telnetd operates like "out of the box".

However, I added a security mechanism, that a some (older?) guys may know as the "wizard code".

With a one-letter-password,
I still believe no-one will be able to actually do an "ls" or whatever.

If there is interest, I can explain how it works and how you can install it (on a Linux/Unix system).

Even if you know the code in advance (with 2 lines left out), you will still have problems to successfully login on my main machine.

Anyone willing to take the challenge ?

Nice day Everybody,
george./

SRP+SSH Vulnerabilities

[Orasis]

Hello, my name is Justin Chapweske and I developed a system called Natz, which is very similar to SRP.

The biggest weakness with Strong Password Authentication protocols like SRP, Natz, and B-SPEKE is that they are vulnerable to a man-in-the-middle attack if the password is known before hand. Thus these systems are worthless for encrypting data to a public resource, like public/anon FTP or a web site.

My biggest issue with SSH is very similar, a man-in-the-middle attack can performed when the server is sending its certificate to the client for the first time.

So basically they both suck, and to this end I have been working on a solution that combines the strengths of both to significantly minimize the cases where a man-in-the-middle attack could be employed.

Oh, BTW, you people that are comparing SRP to SSH based on features don't know what you're talking about. It would be trivial to use SRP allong with SSH or TLS's transport protocols, just using SRP for the authentication/key generation...so quit yacking about SRP not having X-windows tunneling support and whatnot....screw features, its the security thats important.

If you are interested in this, please email me at justin@cyrus.net or continue this thread.

Re:SSHD everywhere?

[pal]

i am afraid of lab machines. even if an implementation of ssh were available, that's no guarantee of any security. how could you tell that there isn't a keystroke logger installed on the machine?

- pal

Re:SSHD everywhere?

[Athos]

I have one word for you. (and a link)

Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty /)

Not perfect, but good.

--

Re: Kerberos

[Jesus Christ]

Kerberos is also available for both Red Hat and Debian.

. . . and almost every other UNIX or UNIX-like OS, not to mentioned Win32. It's not a system for the undedicated, but if you really need (or think you need) that much security, IMHO it's one of the best solutions.

Debian has at least three implementations - two European implementations are on non-US

Yes, unfortunately most Kerberos uses DES, which will continue to be cumbersome unless the US relaxes their cryto policy. We keep hearing about how this is being discussed (or at least I do; I'm in DC), but we've yet to see any concrete results. Alas...

OpenSSH is still an excellent choice, but not because it alone supports Kerberos.

I never meant to imply that that is why OpenSSH is Good Thing(TM). I mentioned the fact that OpenBSD is packaged with this software because I think that is one reason it's a good OS for learning about "paranoid" (read: good) UNIX security. Of course, you can set up most any *BSD to perform similarly, but OpenBSD prides itself on being secure "out-of-the-box". I am not affiliated with the OpenBSD project, but I do use their OS and value the same things they appear to: free UNIX, strong cryto, and the right to privacy.

Speaking of rights, FREE KEVIN! (What?! He did...? When? Why wasn't I notified? Dammit.) Did I say Free Kevin? I meant... FREE WILLY!

I am the Lord.

Re:Encryption style

[Signail11]

16-bit composites can be decomposed into prime factors in much, much, much less than a second. Assuming that the worst case scenario of two 8-bit prime factors holds, a naive brute force test all primes up to sqrt() factoring algorithm takes about 8000 cycles to factor the number (checked using the pentium RTDSC instruction).

Re:I allow telnet in, but only as bait to nab h4x0

[fsck]

Thats called a honeypot.
I did that all the time when I was on the @home cable network. Fake smb shares, fake back orifice (and netbus) server, and a dummy account. I was emailing @home about malicious break-in attempts and c:\ deletion about twice a week. I'm not sure if they took any action though.

Re:But how about the source...?

[drnomad]

Besides, I bet that even bruteforce-factoring a 16-bit prime is faster...

With brute force you must have all primes available for checking, this algorithmn doesn't have these available. It's just a very directive search.

Could you please at least post the inner loop to the web page

There are actually two inner loops (this is a four-way search). Posting either of the loops, or even posting both is pointless as long as you don't know the basic idea behind it.

The most outer loop is the slowest one (and this is the point I'm still working on).

I've done a web site on the explanation of the algorithmn, if I have time, I'll rewrite the thing in more cold-blooded manner (it's too enthousiastic now), and mirror it on a geocities web-site, or any other site which is free.

The order of searches is about O( c* ( Q - (P+1) ) /36 ). I'll look into the size of c.

Re:SSHD everywhere?

[fsck]

Tera Term is free for windohs too, and has SSH plugins.

tera term pro

Re:USe OpenSSH

[Jesus Christ]

WTF? Why was this moderated as "Troll"? AC is not only providing valid information and a good link, but he's right: US crypto is BY POLICY under the big black boot of the NSA. As long as crytography is classified as a munition by the US Gov't (a holdover from the days before computers and e-commerce, when the only practical uses for even *weak* cryptography were during wartime), it will continue to be regulated by the Gov't. The solution is to use open security products, often provided by internationals (if people stop buying US cryto, the Gov't will be under even more pressure from the industry to relax).

The concept of stronger security through Open Source is strange to some, but in time we will be vindicated. Closed-source security stagnates. That's why M$ will *still* be releasing security patches for NT4 long after Linux security problems will have become almost a nonissue (on the OS side).

Jesus says, "If a thousand monkey coders hacked for a thousand years, the monkey coder community would produce a Secure OS. This is the power of Open-Source."

I'm going to stop ranting now. I'm starting to sound like ESR on [more] crack.

I am the Lord.

Re:telnet rulez

[Morrigu]

Problems with this:

(1) You can't or shouldn't be shutting the machine down. Hell, I get pissed off about rebooting for kernel revs. I'll be damned if I'm taking down a box when I know I can avoid it!

(2) The real problem with breakins is not losing confidential data, but that it gives an intruder more resources to launch further attacks. Every machine that gets owned makes more problems for everyone else out there. Your confidential info should be nowhere close to any unsecured network.

(3) If you have to do any useful work remotely, you need some decent encryption. I'll take exploitable (and fixable) encryption over cleartext seven days a week.

I've hacked boxes before from simple sniffer attacks, grabbing POP3 or telnet logins to gain access, and from there compromising the rest of the box. If you don't have packet-level hardware encryption on your network or WAN, for god's sake, use SSH or some other secure app anytime that you're passing logins & passwords around.

It doesn't matter how much you restrict the rest of the system, if a random box on your network (or any point along your communications route) can see your cleartext going by, you're going to get hit hard.

------------------

Re:Encryption style

[drnomad]

16-bit composites can be decomposed into prime factors in much, much, much less than a second

1. The primes were 16-bit, not the composites

2. The algorithmn starts 4 threads, take the time for this startup in account.

Re: hmm

[drnomad]

What's hard is factoring large composite numbers that are the product of two large primes.

This is exactly what the program does.

Your doubts are justified, I wouldn't believe the whole thing myself. The used algorithmn is at least interesting, but I'd like to do some more work te get it faster before I release the basic priciples

doesn't sound like you know enough math

I'm an educated IT-engeneer, I know enough math for my proffesion. For math advice I go to a guy who does know math better than me, but this guy isn't a programmer.

*I* can find primes fast!

[tilly]

It isn't very hard. Finding primes has little to do with factoring though...

Cheers,
Ben

PS Here is a moderately efficient algorithm in an unefficient language:

#!/usr/bin/perl -w
# primes - generate primes
# Written for the PPT initiative by Jonathan Feinberg.
# The algorithm was substantially modified by Benjamin Tilly.
# See docs for license.
use strict;
#use integer; # faster, but cuts the maxint down
$|++;
my @primes = (2, 3, 5, 7, 11); # None have been tested
my @next_primes = (); # Avoid redoing work

my $VERSION = '1.002';

END {
close STDOUT || die "$0: can't close stdout: $!\n";
$? = 1 if $? == 255; # from die
}

chomp(my $start = @ARGV ? $ARGV[0] : <STDIN>);
my $end = $ARGV[1] || 2**32 - 1;
for ($start, $end) {
s/^\s*\+?(\d{1,10}).*/$1/ || die "$0: $_: illegal numeric format\n";
$_ > 2**32 - 1 && die "$0: $_: Numerical result out of range\n";
}
primes ($start, $end);
exit 0;

sub primes {
my ($start, $end) = @_;
return if $end <= $start;
if ($start <= 2 and 2 < $end) {
print "2\n";
}
$start = 3 if $start == 1; # Don't report 1 as a prime
$end--; # Reindex
# Initialize the list of primes
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
while (scalar @next_primes) {
push @primes, @next_primes;
# Careful, we need to ensure that
# we get a prime past sqrt($end)...
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
}
my $from = $start-1;
my $to = $from;
until ($to == $end) {
$from = $to + 1;
$to = $from + 99999; # By default do 100,000
$to = $end if $end < $to; # Unless I can finish in one pass
&more_primes($from, $to);
print map {"$_\n"} @next_primes; # Print primes
}
}
sub more_primes {
# This adds to the list of primes until it reaches $max
# or the square of the largest current prime (assumed odd)
my $base = shift;
my $max = shift;
my $square = $primes[-1] * $primes[-1];
$max = $square if $square < $max; # Determine what to find primes to
$base++ unless $base % 2; # Make the base odd
$max-- unless $max %2; # Make the max odd
$max = ($max - $base)/2; # Make $max into a count of odds
return @next_primes = () if $max < 0; # Sanity check
my @more = map {0} 0..$max; # Initialize array of 0's for the
# odd numbers in our range
shift @primes; # Remove 2
foreach my $p (@primes) {
my $start;
if ($base < $p * $p) {
$start = ($p * $p - $base)/2; # Start at the square
if ($max < $start) { # Rest of primes don't matter!
last;
}
}
else { # Start at first odd it divides
$start = $base % $p; # Find remainder
$start = $p - $start if $start; # Distance to first thing it divides
$start += $p if $start %2; # Distance to first odd it divides
$start = $start/2; # Reindex for counting over odd!
}
for (my $i = $start; $i <= $max; $i += $p) {
$more[$i] = 1;
}
}
unshift @primes, 2; # Replace 2
# Read off list of primes
@next_primes = map {$_ + $_ + $base} grep {$more[$_] == 0} 0..$max;
}

__END__

=head1 NAME

B<primes> - generate primes

=head1 SYNOPSIS

B<primes> [I<start> [I<stop>]]

=head1 DESCRIPTION

The B<primes> utility prints primes in ascending order, one per line,
starting at or above I<start> and continuing until, but not including
I<stop>. The I<start> value must be at least 0 and not greater than
stop. The I<stop> value must not be greater than 4294967295. The
default value of I<stop> is 4294967295.

When the primes utility is invoked with no arguments, I<start> is read
from standard input. I<stop> is taken to be 4294967295. The I<start>
value may be preceded by a single C<+>. The I<start> value is
terminated by a non-digit character (such as a newline).

=head1 BUGS

B<primes> has no known bugs.

=head1 AUTHOR

The Perl implementation of I<factor> was written by Jonathan Feinberg,
I<jdf@pobox.com> and Benjamin Tilly, I<ben.tilly@alumni.dartmouth.org>.

=head1 COPYRIGHT and LICENSE

This program is copyright (c) Jonathan Feinberg and Benjamin Tilly (1999).

This program is free and open software. You may use, modify, distribute,
and sell this program (and any modified variants) in any way you wish,
provided you do not restrict others from doing the same.

Re:*I* can find primes fast!

[wagnerer]

But who cares about primes 2^32. Especially for cryptography purposes. Write a program that will find all the 1024 bit primes quickly and we'll talk.

Re:*I* can find primes fast!

[Silver A]

It isn't very hard. Finding primes has little to do with factoring though...
Cheers,
Ben
PS Here is a moderately efficient algorithm in an unefficient language:

#!/usr/bin/perl -w
# primes - generate primes
[snip]
=head1 BUGS
B<primes> has no known bugs.

Yes it does - if the first number entered is 0, the list will go 2, 1, 3, 5, 7...

To fix, change $start == 1 to $start < 2 in line 30. The documentation reports (correctly) that the range is up to, but not including, the second number entered on the command line. It's not a bug, but it is an annoying feature.

Re:Encryption style

[drnomad]

Try this:

./pfa 2144305103

Takes 0.27 seconds on my Celeron 466 (best time after a couple of retrials).

Note, 4 threads are started here, so I don't know the exact computing time. I'm deeply ashamed, but just found out there's an infinite loop in the prog. This shouldn't happen too often though, but I'll look into it.

Re:Encryption style

[drnomad]

Stop posting anonymously, give me your E-mail, do this thing quiet.

Try a 20 digit number

[tilly]

As a point of comparison, standard general-purpose math programs such as Mathematica can factor ~20 digit numbers (e 70 bits) on commodity hardware in a fraction of a second.

If you cannot come within shouting range of that, your algorithm is not likely to be interesting. If it does then it would be interesting is to know how your algorithm scales to, say, 30 digit numbers...

Ben

FLT (offtopic)

[divec]

>Fermat's Last Theorem is unprovable.

This is not correct. It is a statement about the integers which can be formalised in a first order language, so [by Godel's completeness theorem] there is either a proof that it is true, or a proof that it is false. You could write a program which exhaustively searches all possible proofs (and disproofs). Eventually the program must terminate.

Re:Telnet is the only solution.

[copito]

Nobody says you have to get rid of telnet. Just telnetd.
--

I'm really sorry, but...

[Sangui5]

>>With brute force you must have all primes available for checking

No you don't. A brute force search can just try all possible factors of n up to sqrt(n). BFI is very bad, as it runs in sqrt(n) time (so for a 1024 bit key that's ~ 2^512 computations).

>>The order of searches is about O( c* ( Q - (P+1) ) /36 ). I'll look into the size of c.

Even if your analysis of your algorithm is accurate (I doubt it), it's still hideously poor. That's not any better than the BFI in big-oh notation. Also, the 'c' and the '36' don't matter worth a hill of beans in big-oh. Big-oh doesn't care about constant multipliers of the function. So, it would be more proper to say it's "O(Q-(P+1))".

The best factoring algorthim around is the general number field sieve, which runs in

e^(1.923 * (ln n)^(1/3) * (ln(ln n))^(2/3))

time. The e^ part makes it look bad, but the ln's about cancel it out. That's damn fast for factoring, but damn slow for an algorithm, as it still works out to ~ exponential time if you do it off of the # of bits in the key. It's way better than 2^(#bits/2), though.

#define RANT
This is stuff from freshman year CS. There is no magic factoring algorithm. A lot of people way smarter than anybody on slashdot have spent a shitload of time working on this crap. I've heard that under a hundred people in the whole world understand the math behind the number field theory. You certianly ain't one of them.
#undefine RANT

Same algorithm

[tilly]

Not that implementation (clearly) but the same program works. It is quite fast per prime found. In fact it is so fast that storing long lists of primes is not done any more - it is faster to calculate them than to read them out of storage!

The barrier is that the number of primes out to n is about n/log(n), and so no matter how quickly you list primes, there are just too many primes to list.

So it is utterly useless for cryptographic purposes.

Cheers,
Ben

Oops

[tilly]

I should fix that.

Cheers,
Ben

Overstated vulnerabilities due to buffer overflows

[rambone]

The possibility to hack a site certainly existed.

Please look into the ease with which a buffer overflow can be exploited. Its extremely, extremely difficult.

Buffer overflows should be fixed, but by no means should you remove an entire security suite due to the suspicion of a buffer overflow.

SRP is the secure one - cryptographic reasons

[Paul Crowley]

SSH is secure only if the client has the server's public key with which to authenticate it - and even then there are problems. SSH works in three stages:
1) negotiate an encrypted session with the other party
2) authenticate the other party
3) the client sends the password in the encrypted session.

Clearly, if you can spoof the server you can get the Holy Grail: the real, plaintext password. This is why SSH flashes up big warnings saying "THIS SERVER IS UNAUTHENTICATED: REALLY PROCEED?" when you log on to a server the client hasn't seen before. To which everyone just presses "yes", defeating the so-called security. You can also get the Holy Grail if you can subvert a server to which the target logs on.

Contrariwise, SRP offers real network password security. SRP was designed around the assumption that the normal situation for network security was that people went up to new, vanilla clients and used only their passwords to log on to servers the clients had never seen before, and any protocl that wasn't secure under these assumptions just wasn't secure. SRP does damn cunning public key manipulations to allow the password to be used to verify both the client *and the server*, while only storing a password verifier on the server. Eavesdropping real connections, spoofing clients, or spoofing servers will leave you no better off than when you started; you can't even launch a dictionary attack, in contrast to disastrous protocols like CHAP which don't work for the low-entropy passphrases used in the real world. You can mount a dictionary attack if you subvert the server (this is unavoidable), but that's still more work than just reading the plaintext-equivalent phrase from the password file as is the case with challenge-response protocols; even subverting the server doesn't help.

SRP (and its cousin, B-SPEKE) solved the real, difficult problems of network password security. Accept no substitutes.

I only wish Slashdot didn't prioritise being first over being right so much, so more people could see the good information...
--

Re:SRP is the secure one - cryptographic reasons

[Tuck]

This is why SSH flashes up big warnings saying "THIS SERVER IS UNAUTHENTICATED: REALLY PROCEED?" when you log on to a server the client hasn't seen before. To which everyone just presses "yes", defeating the so-called security

That behaviour is optional. You can enforce good host key hygiene by adding "StrictHostKeyChecking yes" to /etc/ssh_config.

StrictHostKeyChecking

If this flag is set to "yes", ssh ssh will never automatically add host keys to the $HOME/.ssh/known_hosts file, and refuses to connect hosts whose host key has changed. This provides maximum protection against trojan horse attacks. However, it can be somewhat annoying if you don't have good /etc/ssh/ssh_known_hosts files installed and frequently connect new hosts. Basically this option force the user to manually add any new hosts. Normally this option is set to "ask", and new hosts will automatically be added to the known host files after you have confirmed you really want to do that. If this is set to "no" then new host will automatically be added to the known host files. The host keys of known hosts will be verified automatically in either case.

The argument must be "yes", "no" or "ask".

Re:SRP is the secure one - cryptographic reasons

[tjw99]

If you set this option, it sounds like either the administrator or the user has to go around manually maintaining the ssh_known_hosts file. The goal of SRP is to avoid having to trade off security for convenience - there's no known hosts file to maintain with SRP, yet the system still resists server spoofing. SSH can't offer that protection until it incorporates a ZK password method in its authentication stage, a la LSH-0.9.

Network Topologies and sniffers

[Jason Pollock]

The university I went to had a problem with people attaching sniffer's to ports, so they went to a completely switched ethernet network topology for all of the lab terminals. Problem solved. :)

Security always comes down to trust. Do you trust the guy at the other end of the line or not? Can you really not trust ISP networks?

For example, if I am on a cable-modem, and my target is on the same cable-modem network, isn't the data already encrypted end-to-end?

Jason

Re:Network Topologies and sniffers

[Effugas]

Switched networks are (at present) irrelevant to a determined attacker--I send out a gratuitious ARP identifying myself as the MAC to send all your IP traffic to, everyone sends me your traffic, which I then A) Read and B) Send along to you with a forged MAC address.

Really nasty when you do this to the gateway.

Defeating this requires security mechanisms which are rarely deployed at the switch level.

See the dsniff toolkit for example code.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

This makes me smile :-)

[T-Punkt]

If I ever find two lifes, I promise, I will give one to you. (fingers crossed)

And to babelfish something back:

On the search for the missing persons the space cruiser " the Unbesiegbare " pulls comrades by the ALL. On Regis III the astronauts meet puzzling remnants of a high-technical culture. Dead subject, according to long senseless rules become programmed, pursues and sells the intruders.

And for our French friends:

Thank you!

[ballsbot]

I don't know why, but this site wasn't turning up on my searches. I've been looking for where putty came from from a number of months now.

As a vote of confidence for this particular ssh client, it's a great little program, i've found *no* bugs in it, it's easy to use, and (best of all?) it's open source.

Key Theory

[Effugas]

OK, thought about this a little.

SRP essentially combines the concept of "Hashed Password" and "Secret Key" into one small, low entropy object: The stored password.

"Dictionary attack" difficulties aside, it's not hard to imagine an intruder running a pre-computation attack against a password file. *However*, the password file *can be* much more secure--crypt() is far less secure than SHA-1, though SHA-1 isn't drastically better than the MD5 passwords deployed on most Linux boxen.

It is moderately unclear through the documentation how the "public verifier" gets distributed; more emphasis should be placed on this. The public verifier, distributed via OOB mechanisms, is *the only* way to get around "first contact" problems. Now, the public verifier can be shared, extended, chained, and so on, but at some point there has to be a Out Of Band(OOB) contact.

Of course, the problem with chains is Entropy Erosion and Failure Amplification--your original entropy never increases, but your risk of compromise *does*.

Another brought up a good point--SSH ideally requires compromise of both a private key(what you have) *and* passphrase(what you know) to experience a critical failure; SRP only requires one. One nice thing is that SRP can mandate that a user have a passphrase; I don't believe SSH has a truly secure method(not client based) to make sure that they don't.

More later, if anyone's still alive in this thread. (Gotta go.)

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Re: NFS within SSH

[That Nebulous Entity]

(Due to the author's total ineptitude in getting Slashdot to acknowledge his existence as a non-AC, the below post is being repeated. After all, a post that says 'email me' without an email link is useless... unless you're a psychic.)

I'm planning on implementing one as a final project. We'll see how fast we can get it, and whether or not it will be functional.

Points to consider

[tjw99]

I'm Tom Wu, the inventor/devloper who designed the SRP protocol and currently maintains the distribution. Some points that I think should be borne in mind:

• Comparing SSH and SRP is a bit misleading. As others have pointed out, SRP is an authentication method, and while there are applications that support SRP directly, like secure Telnet and FTP, there is no reason that SRP can't be used, say, as an authentication mechanism for SSH.
• SRP is supported by at least one version of SSH, namely LSH-0.9.
• SRP offers the type of security one expects from SSH with RSA authentication (resistance to MITM attacks) with the convenience of standard passwords.

Keys tied to computers? Indivviduals? Try both!

[smurfi]

the key is (effectively) tied to one or more computers rather being tied to the individual,

You can set up ssh to have per-host keys and shared user ID space. Sure -- just like rlogin with encryption.

But you can use per-user keys just as easily. It's all a matter of choice , which is a Good Thing.

Since SRP isn't about encryption anyway (their website says so), but "only" authentication, then why would I want to use it? If somebody can watch me type and they see my screen output, they don't need a login on my system anyway.

Re:Keys tied to computers? Indivviduals? Try both!

[tjw99]

SRP securely exchanges a session key in the process of authentication. This session key is used to encrypt session traffic.

With SSH, you trade security (RSA authentication) for convenience (user password authentication); SRP gives you both at the same time.

Re:Telnet is the only solution.

[lgas]

Not to mention that these days, unless you have a massive investment in security, if a hacker gets the login/password of a non-root account, that is pretty much equivalent of having root on just about any version of UNIX. In my experience it is very hard to get into a well-protected machine from the outside, but once you're on, there's always a way to get root that can be found in 5 or 10 minutes of poking around. If your machine is pretty tightly locked down from the outside, and you always use SSH or some similar sniffer-proof method of logging in, you're in pretty good shape. If on the other hand, you use telnet or some other insecure form of logging in, you might as well not have passwords on any accounts including roots. It's probably also worth mentioning at this point that having your host on a switched network make some people think they are impervious to sniffing, but if you are going over a WAN to the switched media, it makes no difference, and if your switch has a monitor port and the switch is not well protected you're just as vulernable. Might as well write your passwords on yellow stickies and put them on the top of your monitor.

Does it run on *nix, Win32, MacOS...

[randombit]

When and only when nice graphical interfaces for Windows, MacOS, etc (ala TeraTerm SSH, SecureCRT, DataFellows SSH, etc) exist for SRP will it be possible for be possible for it to replace SSH: face it fellas, most clients are Windows boxes, and if the clients can't connect to the server securely because either clients don't exist for the OS or the users won't use them because the interfaces suck, who cares if it's secure? Also, SSH is, as far as system integration is concerned, very easy to do.

Re:FLT (offtopic)... JOKING?

[Beethoven]

I hope you have tongue firmly in cheek.

See Godel's Incompleteness Theorem.

You're right, though, from what I've heard, FLT was proved.

SSH is somewhat secure against MTM

[Djinh]

The only time a man-in-the-middle attack would work with SSH is the first time you connect to a host. Any time after that your SSH client will compare the host's key to what it has stored in ~/.ssh/known_hosts.

Re:SSH is somewhat secure against MTM

[tjw99]

SSH *is* vulnerable to MITM, and not just on the first connection. If the host advertises a public key different from the stored key, ssh outputs a loud message to that effect, but allows the user to continue anyway. Here's the kicker - this also happens so often when connecting to legitimate servers that users are practically forced to say 'y' each time or else not get their work done.

SRP does not have this vulnerability, and does not require the user to make this tradeoff because it prevents the MITM attack with better cryptography.

Re:If only I could SSH

[frost22]

Quoting:

Source: You can freely use this program. Source is not available and I am ignoring all e-maill messages with request for it. If you dislike such policy, please feel free not to use it.

I suggest following the authors's advice: Do not use that. This policy stinks

Check Out Teraterm with the ttssh module. Nice, Stable, complete, widely in use, and all the source is available.

--f

Re:Telnet is the only solution.

[WWWWolf]

Nay... You obviously meant netcat. telnet can only do tcp. =)

(Seriously, though: I use ssh for work, TinyFugue for play and netcat for scripts. =)

Re:PKI and other issues, Interlock protocol

[bluGill]

This won't work for all man in the middle cases. Consider this:

1)A sends B is public key
C intercepts that key can changes it to his public key
3)B sends A his public key
4)C intercpets and changes
5)A sends C a message encrypted with C's public key.
6)C decrypts and recrypts with B`s public key
7) B sends half the message encrypted.
You get the idea

Remember for this to work A and B have to have no non-seceret knowledge of the other that C does not share, and C needs compete high speed access to the entire data stream. Of course if any step is accomplished where C cannot get it (snail mail? federal crime, but doable. Meeting face to face can be fixed too, with impersonators.)

In the end you have to take some risk. Then again, if A and B know so little about each other and are doing buisness that is sensitive enough to encrypt they probably don't trust each other at all anyway.

Re:No one has claimed to have "rooted" NT using pc

[Chexum]

bullshit I know for a fact of a certian search engine that is a top 25 web site that got hacked through pcAnywhere

Wow. by Anonymous Coward hirself, citing reliable sources on a reliable target, slashdot credibility at its best...

(Not that I have too much faith in the named software...)

Re:ssh tutorial

[NetNrrd]

SunWorld had a two part tutorial on setting up and running ssh a while back. Check it out.

RSA License and RSAREF

[_Sprocket_]

SSH 1.2.x only links against RSAREF if you tell it to. This is only an issue for places where the RSA patent is valid (which, by the way, expires in September of this year).

No good deed goes unpunnished.

Those who actually tried to stay within a quasi-legal standing in compiling SSH1 with RSAREF ended up with an insecure implementation. The thing to consider here is... did it buy them much? There is still some question whether using RSAREF actually allows one to avoid licensing issues. I wouldn't be suprised to find more installations of SSH1 today compiled by admins who got fed up with the whole situation.

As a side note, admins working for the US Government have no need to worry about RSA licenses. The US Gov't has an open license to RSA since Government money was used in developing RSA at MIT.

fuck off, luser

[Jesus Christ]

As you can see, the slashdot environment can be very hostile, so I have no reason to publish the source codes.

You just don't get it, do you? You expect Slashdotters to download your binaries off a Geocities site, when you can't even give a decent explanation of what your program does. Then several people with obviously a much greater quantity of brains than you go on to show how your "algorithm" (and I use the term very loosely) is not only logically flawed, but is completely irrelevant, due to the fact that much better programs already exist.

The enviroment isn't "hostile" at all. We tried to have a very rational discussion with you. You lack the mathematical knowledge to clearly explain your "algorithm", so you call us hostile? What gives? A previous poster had a good point: with all of the genius mathematicians and computer scientists that spend their lives studying number theory and cryptoanalysis, an self-proclaimed "IT engineer" (who could be little more than a haughty MSCE) had better be prepared to explain himself when he claims to have discovered an algorithm which can "find primes fast" (bold yours).

"Fast" is relative. "Fast" implies that it's fast compared to modern existing programs. Your examples were piss-poor. Signed 16- and 32-bit numbers are hardly crytographically relevant anymore. Then, you say that you gave the best times out of a few trials. Wow, how scientific of you.

You "have no reason to publish the source codes?" No-one wants them! The only reason someone asked you to post the loops is because you couldn't explain your own concept.

"Hey, guys, I have this really fast algorithm I came up with! You can try my l337 Linux binaries, 'cause I'm so generous! What does it do and how does it work? Well, I can't really explain it... and I don't want to let you see the code, because when top university scientists from around the world discover what a genius I am, I want to be able to talk all the credit. Hey, stop using big words and intelligent sentences, you meanies! Forget it, I'm taking my amazing program and it's amazing source elsewhere!" What a fucking dipshit.

I am the Lord.

Who says SRP is not patented?

[nealmcb]

You write "SRP isn't encumbered by patents".

I see little evidence for this, and there are lots of hints otherwise. Previous versions of the SRP license contained the warning

"Some of the algorithms in this distribution may be covered by patents in some countries; it is up to the user to ensure that any required licenses are obtained."

The page http://srp.stanford.edu/ says "This link is currently limited to Stanford users pending resolution of patent negotiations. Sorry!"

Two years ago I sent email to Thomas Wu asking if it was patented and got no response. Other people I've talked to also are concerned about this.

So while I can't point to clear evidence of patents, I urge great caution with SRP until a definitive answer on this question is provided. I like SRP, but the advantages over SSH are marginal enough that the intellectual property questions are far more important.

On another front, SRP is promoted because it allows users to choose their own easily-remembered passwords. But Bruce Schneier notes that computers are already fast enough to basically search the entire space of passwords that are easy for humans to remember. So if the password file on an SRP server is compromised, the passwords can be cracked if you try hard enough. I'm sure it is very expensive now, but over time the cost of doing this will drop since human memory capacity is not increasing.

--Neal

Re:Who says SRP is not patented?

[tjw99]

Even if a patent is granted for SRP, it will remain available on an Open Source-friendly basis.

Also keep in mind that any password-only system must keep its server database secure, since a compromise can lead to a dictionary attack. SRP offers the maximum possible level of security while still using re-usable passwords. If you want better security, you need to sacrifice the convenience of re-usable passwords.

Re:Who says SRP is not patented?

[nealmcb]

Cool. This is positive, though ambiguous news, but it comes from an anonymous source, "tjw99 on slashdot" (ironic for a debate about authentication :-)

Is this really is the very inventor of SRP, Thomas Wu, speaking? Assuming that it is, welcome to the party! I'll make the same plea I made in email to you 2 years ago - splash this news all over the web page! I think the world will take SRP far more seriously if you will put that in writing and avoid ambiguity. E.g. can people sell their own SRP implementations without a license? Without a fee?. The appropriate way to do so is to write a letter to the IETF along the lines of

http://www.ietf.org/ipr.html

It will need to be in legal language. In my experience, IETF won't be interested in putting it on the standards track unless it uses the model of the SSL patent from Netscape: free for *all* uses (not just open-source or non-commercial), reserving only the right to use it defensively, i.e. preventing other companies from going after you for infringing patents on SRP-related stuff that they may assert. E.g.: from RFC2246 on TLS (the successor to SSL):

Netscape Communications has issued the following statement:

Intellectual Property Rights Secure Sockets Layer

The United States Patent and Trademark Office ("the PTO") recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to Netscape for inventions described as Secure Sockets Layers ("SSL"). The IETF is currently considering adopting SSL as a transport protocol with security features. Netscape encourages the royalty-free adoption and use of the SSL protocol upon the following terms and conditions:

• If you already have a valid SSL Ref license today which includes source code from Netscape, an additional patent license under the SSL patent is not required.
• If you don't have an SSL Ref license, you may have a royalty free license to build implementations covered by the SSL Patent Claims or the IETF TLS specification provided that you do not to assert any patent rights against Netscape or other companies for the implementation of SSL or the IETF TLS recommendation.

What are "Patent Claims":

Patent claims are claims in an issued foreign or domestic patent that: 1) must be infringed in order to implement methods or build products according to the IETF TLS specification; or 2) patent claims which require the elements of the SSL patent claims and/or their equivalents to be infringed.

Thanks, Thomas!

--Neal

Re:SRP and patents

[tjw99]

Regardless of whether or not a patent is issued, SRP will be available under the current Open Source-friendly license. There are *no* patent problems using SRP - enabling strong Open Source authentication was one of the major reasons I invented SRP.

Completeness Theorem != Incompleteness Theorem

[divec]

> I hope you have tongue firmly in cheek [...]
> See Godel's Incompleteness Theorem

Ah, these are two different results. Godel's Completeness Theorem says that any *first order* statement which is true can be proved. "First order statements" are, essentially, mathematical statements which only talk about certain things. Amongst other things, first order statements can't talk about "For all sets such that blah".

On the other hand, there are statements which do include things like "for all sets such that blah " - called second order statements. Godel's *Incompleteness* Theorem says that there are some second order statements which are true but cannot be proven.

My comment was that FLT fits into the first category, so an automated proof is (theoretically) possible. Of course, it would take ages to run!

Re:Telnet is the only solution.

[jovlinger]

Lovely,

apparently this post was is the same category as "PERL sucks! Python Rulez!".

Hillarious.

FLT not undecideable

[divec]

If FLT were undecideable, we'd be able to find a model of the natural numbers in which it was false. There would be a counterexample a^k + b^k = c^k in this model. But (a,b,c,k) is a finite [ordered] set of natural numbers, so it is a decideable set, so it exists in any model of the natural numbers, and so a^k + b^k = c^k would hold in any model. But then (Exists x,y,z)(x*...*x + y*...*y = z*...*z), so we have a disproof of FLT which holds in any model.

there are Diophantine equations which are unprovable in Gödel's sense

Not quite - what Chaitin showed was that there's no single algorthim for solving all Diophantine equations.

Re:FLT not undecideable

[divec]

Sorry, I should have said that the products m*...*m were meant to be k times.