I am working on iPhone application which have login form to access application functionality same as website. now i want to add one button in iphone application that redirects user in to website in safari browser with successfully login.
After success login in to iPhone application, user want to check website in browser so i just need to add functionality that user can directly login in his account and redirect on particular page.
i have some basic idea for that we can do with encrypted username and password with url.
like http://xyz.com/login/username=abc&password=abc
but i know that its not secure way to pass username and password with url.
So please suggest me any other way if possible.
Any idea or alternative that how to implement this.
Thanks in advance.
There are a few ways to do it.
Any time you send password information over the Internet you want it to be encrypted over SSL. This will require an SSL Certificate for your web server though and it's not always possible.
You can also encrypt the username and password yourself in a way that only your web server will know how to decrypt. So the username "foo" could be turned into "oof" and the password "bar" could be turned into "rab". That way if someone intercepted your requests, they couldn't know what the username and password were without knowing how you changed them.
Why not pass the session id?
Here's what I mean: When you log in to a web site, typically you're assigned (or already have) a "session cookie" which essentially tells the server "This visitor has session ID 'XYZ'", and allows it to retrieve the server side information stored for that user (like who they are, that they authenticated, or whatever else you store in the session store.
One of the easier ways of moving to/from applications is to make sure that all logins generate a server side session, and provide a script which will overwrite the user's session cookie and redirect them to the proper page.
session_restore.php?sessionId=12345&redirect=HOME
The doubters here will argue that providing such a script is tenement to a security breach, but I would argue that all of this information is stored client side already, and can be accomplished without the server's intervention anyway. (session hijacking plugins for popular web sites exist for firefox that will grab session IDs from wireless networks - no technical skill needed)
Doing it this way just makes the process friendlier to the user, and if your site provides SSH access (which you really should be doing anyway) then the risk is very minimal.
Related
I have a simple webpage deployed to tomcat which runs certain shell scripts based on user selection. The pages are written in html and cgi/perl.
We already have a working ldap server and directory. I need to be able to add security to the web page I created so a user is asked to login using their ldap account when trying to access the home page or any off the sub pages.
How do I add ldap authentication to my web page?
Please be very specific as I am new to all of this. Step by step instructions including code would be greatly appreciated. Thank You
I did a lot of research on google, but all of the solutions are generic, and I don't know where to start.
This is a good article, but I'm not sure where do I put my connection to ldap and the binding (which of my pages)? How do I make sure the authentication will apply to the sub pages as well, or any other one created in the future?
http://www.perlmonks.org/?node_id=32196
Cheers
This is a good article, but I'm not sure where do I put my connection
to ldap and the binding (which of my pages)? How do I make sure the
authentication will apply to the sub pages as well, or any other one
created in the future?
You're now adding state to your app. You might initially think about implementing your authentication (authn) and authorization (authz) in tomcat, and not in your app.
If you decide not to implement in tomcat, and choose to implement in perl, then you've just decided to add state to your application, which means you need to add some kind of session handling. Look at CGI::Session, there are many other session handling modules on CPAN. Avoid Apache::Session. Its lock handling can cause lots of pain if transactions run long. Use a session key in a cookie. Send everything over SSL. if you don't use SSL, then crackers can intercept your session keys, and then hijack the sessions.
Once you have your session infrastructure set up, you need to create a login mechanism, usually a form with username and password. when that form is submitted, the CGI behind it does its magic crypto on the password and then does the LDAP dance:
connect to the directory server is no connection already exists.
2a. bind to the server anonymously or as an application user, search for the user by CN, bind as the user using DN and password
OR
2b. compute the DN form the username, bind with the DN and the crypto's password.
Often, step 3 is to check the user's record for some authorization indicator, it could be a yes/no access indicator, or it could be a list of roles or privileges.
If the user is successfully authenticated, and authorized, then write some authorization info into the user's session.
Each subsequent page of your app will then check to see if the user is logged in and/or has the proper authz to use that page. If unauthorized, you can either send them back to the post-login landing page, or to the login page if they aren't logged in.
Basically, you just replacing the usual "query the user table of the database" with a query to an LDAP to a directory server.
I want to make an app having financial Transactions for iPhone.So, my first target is to make a login page(and that's where my problem starts):-
The Admin or customer Details are stored in MSSQL DB.Now, when the client enters his username and password in my app, i want to verify these Credentials. So how can i do this?
Acc. to my little knowledge, i cannot connect to the DB directly, I need some web service or something as a middleware(but don't know what).I cannot parse the url directly to check the credentials as it will not be safe.Did we have to Encrypt the Credentials of client and if yes then how can i retrieve and verify the Login?
Any Sample, Links or anything will be helpful.
Create a .net site with a login.aspx web service page where you will handle authentication for the app. Make sure to get a HTTPS/SSL cert set up on your site as well.
Call me overly cautious, but I hate the idea of direct web server database access from a client app, I always like a middle layer of control/protection.
Edit
for example, you app can make server calls similar to this (using POST of course): yoursite.com/webservice/Login.aspx?username=chucknorris&password=somepassword&appkey=679384820473487746
Then on your Login.aspx page (or other pages for that matter) you would check for the POST variables (username, password, etc) and ask the database if they match. If they do then have the page return a success message, or do whatever additional processing you desire.
On multiple page requests within a certain amount of time, you can optionally use session states or go the more RESTful type of route, both are easily researched via Google.
POST + SSL is a must for basic security measures.
I'm creating an iphone app where the user logins once (when they open the app for the first time), then will never have to login again (like how instagram does it). The app will automatically log them in the next time they open it up. However, the app makes a bunch of requests to a web server.
What is the best way for the server to issue session tokens? How long should the session tokens be valid for? How can I ensure the user never has to log in again, while still providing secure session tokens.
One approach is for the server to issue a token to the user when the user logs in for the first time, and make that token permanent. That, however, does not seem secure.
Thanks for the help!
Well, generally the session is already handled through session cookies. Unless you're planning to have third parties connect to your service, I think it's a bit overkill to do anything besides basic http authentication. I would definitely send all of your connection requests over an https connection though.
As far as persisting the session on the iPhone side, you can save the user and password in the Keychain, and then automatically retrieve and send it to the server when it requires you to log in again, without having to prompt the user to log in again. How often you want the sessions to last on the server end is really up to you.
What is the best way for the server to issue session tokens?
One way to do it is using OAuth. It is more complex than cookies but it has more features.
A token is granted to each application and can be revoked by the user from a page in the server. This token can be permanent or temporary. You can store it as plain text or inside the iPhone keychain, depending on the level of security you need. There is open free code for server and client implementations. Another benefit is that clients can log in your service using their Twitter/Facebook/... account so they don't need to register on your site.
I'm building an app that performs similar functionality that one website does: register, login, submit order, view orders and etc. Now, do I have to do anything explicitly in order to get things working?
After successful login, a webserver establishes a session and sesssion ID and related session info is written to related cookie. IMHO, I just need to call webservice with login credentials and then the rest will be done implicitly. After successful login, every requested user page from user area will be checked with sent cookies and session file at server side. So, do I have to do anything else in order to get into secure area?
Agree with what #sicKo has said. Remember, sending data over wireless network is not secure. Do be careful on the transactions when money and authentication involved.
In addition to what #sicKo has said, you may now consider the coming iOS5, store the value at iCloud.
You just have to send the value to verify the user to the webserver.. and u can keep the session alive in iPhone using NSuserdefault..
U might want to encrypt the sensitive data send over the network such as username and password.
How can I implement a cookie based single sign on without a sso server?
I would to share the user logged in across multiple applications using
only a cookie on the browser.
In my mind it's working like this:
user logs in an application
the application verifies the credentials and then it setting up a cookie on
the browser storing the username (that could be coded with a private key)
if the user opens another application, it searches the cookie and reads
the username on the value (using the key for decode the string)
In this solution a user may see the browser cookie (of a another user)
and take the string codified of the username. Then he could adding it on
an own cookie (no good!).
There's some secure way to do this? With a timestamp based control or
something like this?
Thanks in advance.
Bye
P.S.
I know that my english isn't very well.. sorry for this!
This is impossible. Cookies are unique to each domain, and one domain cannot read another domain's cookies.
I think the answer comes a little late, but maybe I can help someone.
You can have a cookie / localStorage in an intermediate domain connected to the home page using an iframe
1) Login
The login form in any of your domains deposits the identification token in a cookie on sso.domain.com by an event (postMessage)
2) Verification
domain1 and domain2 include a iframe pointing to sso.domain.com, which reads the token and notifies the home page
To simplify development, we have released recently a cross domain SSO with JWT at https://github.com/Aralink/ssojwt
There is a simple solution without using an sso server, but not with 1 common cookie, as we know that cookie's are not shared between domains.
When the user authenticates on site-a.com, you set a cookie on site-a.com domain. Then on site-b.com, you link a dynamic javascript from site-a.com, generated by server side script (php, etc) who has access to the created cookie, and then copy the same cookie on site-b.com on the client-side using js. Now both sites have the same cookie, without the need of asking the user to re-login.
You may encrypt/encode the cookie value using a method that both site-a and site-b knows how to decode, so that site-b will be able to validate his cookie copy. Use a common shared secret that without it will be impossible to encode or decode.
You see that on the 1st page load of site-b.com, the cookie is not present, therefore if you see necessary, you may want to do a page reload after setting the cookie.
I have done something similar. There is a PHP application where the user logs in, the system contact a web service and then the service checks the user's credentials on the Active Directory. When the user is authenticated, his PHP session is stored in the DB. Another web application can read the PHP session from the cookies and uery a web service in the PHP applicaiton, the PHP application check the session in the database and return the user id. In this way I have a SSO using SOA.
Do not rely on the user id stored in the browser, is a security error, at least encrypt the id.
The best solution would be to put the login form and session storage in the same application, then this application can provide services to other applications.
And use HTTPS for the kind of infomation exchange.
The cookies can be read only if the belongs to the same domain, for instance:
intranet.example.com
crm.example.com
example.com/erp
You can access cookies across subdomains, but I do not think using browser cookies is a great solution. You really don't need a "SSO server" to implement a single sign-on. It is fairly easy to come up with a payload that both applications recognize. I have seen custom SSO solutions that transmit the payload using XML over HTTPS.
Here is a solution (which will hopefully get heavily scrutinized by security gurus on here):
Have each domain store user data in a similar cookie, and when a user want to jump from one domain to another without authenticating themselves on the new domain, provide a "jumplink" with an encrypted token in the query string. The new domain would decrypt the cookie, and figure out who the user is, then issue them a new cookie for that domain. You would want the "jumplink" to have a very short expiration date, so I would not generate them right into the page, but generate links to a "jumplink" generator and re-director.
This might not be necessary, but the receiving page for the "jumplink" could make a web service call back to the originating domain, to verify the authenticity of the encrypted token and the whether it's expired.
I think this solution would be susceptible to man-in-the-middle attacks (not sure if it would be more so than other auth mechanisms which are currently popular), but you could incorporate a client MAC address and IP address into the encrypted token for extra security.