Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm developing a program that contains a login function in C++. The problem is that I don't know how to develop it in my situation. I want to run the software on a raspberry pi, it only has a CPU clocked on 1 GHZ and 512MB of memory. The Memory isn't going to cause a problem, but the CPU does.

The problem is that I can't effort a lot of CPU power on encryption, of course I encrypt all passwords, but I can't encrypt the connection. This is because I think that HTTPS is to heavy. No HTTPS is not a real problem because the data is not classified, but I want to make sure that no one else can capture the connection and preform actions.

This is what I designed till now:

The login functions validates the user, if a correct user name and password is given then the user gets a unique encrypted number. The user must send this number every time to get access to his account.

The problem:

The problem is that every one can capture the unique number of the user, and he could use this number to login to his account. How can I develop a login function with out this problem? I can use the users IP in the encrypted number, but this is not secure when the hacker has access to the targets network.

Besides that, the user sends his credentials over the network. I guess I can also preform some encryption client side, but this isn't very handy for my CPU because I need to do more encryption cycles on my server.

share|improve this question
    
To make clear why I didn't choose for HTTPS: The target is to create an efficient implementation that doesn't wast CPU power. A requirement of my project is to create everything as efficient as possible. Efficient is more important then time when there is a visible performance improvement. So when I could create something that is 10% more efficient but it cost 20% more time, then I’m willing to spend the extra time to get 10% more performance. But this needs to be on a part of the system that has a great impact on the performance. An encrypted network connection is a big part. –  Laurence Dec 21 '12 at 14:19
add comment

4 Answers 4

up vote 5 down vote accepted

HTTPS is not too heavy for an RPi at all - they're surprisingly powerful, and SSL is very lightweight in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers.

If you don't believe me, consider the fact that you can SSH into an RPi with no issues at all.

share|improve this answer
    
That is also true, the only downside is that the browser can't cache data. Images need to get downloaded every single time. So it will take a lot more bandwidth. But I could do some tests with libcurl. Thanks! –  Laurence Dec 21 '12 at 13:17
2  
Browsers cache HTTPS data, if you set the HTTP headers right. –  Matrix Dec 21 '12 at 15:56
add comment

SSL will be quite heavy on an Pi ARM processor compared to vanilla HTTP connections. Back when normal server processors were 1Ghz, I tested performance of SSL with various SSL hardware accelerators at the time. Typically, SSL would drop to 15% of the performance of vanilla HTTP for apache, IIS etc at the time.

HOWEVER. It is the SSL handshake, i.e. at connection, that uses up the cpu. So if you can minimise this, then the overall CPU usage will become less of a problem.

There are two strategies:

  1. map out the performance model for your app. If the clients are creating new SSL connections all the time then you may suffer performance problems. Perhaps consider maintaining longer sessions between requests and this will reduce the load.
  2. Use mutually assured SSL, i..e with client side certificates. This reduces the CPU load on connection to close to that of vanilla plain text HTTP.

SSH appears to work quite well with my Pi (but not applicable in this scenario)

share|improve this answer
    
An other problem of HTTPS is that you are encrypting data that doesn't need to get encrypted. This is just a wast of CPU time. I know it is secure, but there needs to be a better way that takes less power. You are 100% ride when you are logging in to a bank account, but I'm building a browser game, it doesn't matter if some one else knows how many supplies some one else has. It doesn't harm the user. The only thing that matters is in this case the users password and that some one else can't send an action to preform by another user. –  Laurence Dec 21 '12 at 13:32
add comment

I know of a 50 MHz PowerPC processor which runs a SSL server and routinely handles 70 simultaneous clients; I wrote the code myself. SSL is not heavy. Also, I cough and shriek when I hear about a 1 GHz processor being "slow": a Raspberry Pi would have been a totally rad gaming station back in 2001, and the Internet already existed at that time...

If you have some fetish about CPU cycles, then the good idea is still not to design your own protocol. Instead, use a properly configured SSL (e.g. with elliptic curves for the asymmetric cryptography).

share|improve this answer
    
Now I'm 100% sure that I don't know anything about the CPU time that encryption needs. I'm going to try it soon, thanks you very much for your answer. I'm sorry that I marked Polynomial answer as correct, but you have my upvote. –  Laurence Dec 28 '12 at 7:30
add comment

You are basically implementing a session system. Read more about securing it at https://www.owasp.org/index.php/Session_Management_Cheat_Sheet and https://www.owasp.org/index.php/Session_Management. You basically want to prevent session hijacking and replay attacks. One of the defenses is to bind the session to a client IP address and require re-authorization if the IP address changes. Search the web for more, keyword is "session hijacking".

For best security, you need to use HTTPS. You can minimize the amount of resources that HTTPS (SSL/TLS) uses during the handshake by using 1024-bit RSA certificates instead of standards 2048-bit. For symmetric cipher, use RC4 instead of AES, because RC4 uses less CPU, which is probably why Google is using it, although that should soon change with AES-NI support.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.