I have problem with OCRA generation, the client and server need to agree on one or two values of OCRASuite but I can't find any information about OCRASuite on official PROTECTIMUS site.
Please, check out the following OCRASuite:
OCRA-1:HOTP-SHA1-6:QA40-T1M
Related
Using token,token secret,Consumer key,Consumer secret,time-stamp,nonce i generate the signature using developer account but it always shows the Signature invalid while connect the fast link of yodlee, May be the generated signature method wrong, Can any one provide the Lib's for generating signature using java.
Could you please provide the request you are generating? Meanwhile, can you please take a look at integration guide present here.
Thanks Apoorv for your replay.
The below url i generated https://fastlink.yodlee.com/appscenter/fastlinksb/linkAccount.fastlinksb.action?access_type=oauthdeeplink&displayMode=desktop&oauth_callback=http://www.google.com&oauth_consumer_key=XXXXXXX&oauth_nonce=her1lk40NpL&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1407732923&oauth_token=9819d4247f9f44959510832bc6688b86&oauth_version=1.0&oauth_signature=IRVbo09jAub0FTtt7uLMPA==
please verify this and letme know what is the mistaken
I noticed this as well after looking at the oAuth 1.0 sample code. If you enter your callback url without the protocol it will work. In your case just enter www.google.com. When you need the protocol you must url encode the querystring parameter.
https://fastlink.yodlee.com/appscenter/fastlinksb/linkAccount.fastlinksb.action?access_type=oauthdeeplink&displayMode=desktop&oauth_callback=http%3A%2F%2Fwww.google.com&oauth_consumer_key=XXXXXXXXXXXXXXX&oauth_nonce=6238157&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1407996476&oauth_token=11232e9a123111111d8a19175663ecd947&oauth_version=1.0&oauth_signature=4RbNDY9z1wC/vMV5neitQa7ZxQM=
While generating the signature you also need to include the URL and parameters. You can find libraries on JAVA for generating signature at Oauth JAVA
Also if you want to invoke the FastLink in a browser for testing then you can use steps from this article
I get how to store passwords on a server, but what about a client that will automatically login to the server? What's the best way here? Should I store a hashed password, and have the server double hash? Should I encrypt it? What options are available?
This software will be open source, so any keys used are publicly available.
EDIT:
This is actually a computer program. I can send stuff off like MAC addresses without a problem.
It all depends on the level of security you want to reach :-)
Also look here where this topic is discussed in detail: Designing a secure auto login cookie system in PHP
Edit: Even more detailled http://jaspan.com/improved_persistent_login_cookie_best_practice
and yet another very very good post about the whole topic: The definitive guide to form-based website authentication look at PART II
As far as I'm concerned, cookies are sufficiently safe to save the password in cleartext. It is only a problem if you have an XSS leak or someone saves it on a public computer, so another person can look it up.
In that case, I would go for the solution you suggested with hash on clientside and double hash on serverside.
EDIT: I just realized, that they can be read out (with ease) when using an (unsecured) WLAN, too, so now it seems to be a bad idea to save them in cleartext.
Are there any guidelines or best practices for handling expired passwords for scenario with active clients via WS-Trust?
For now I have couple of ideas, but can't find any info about it:
1. Issue special token, so client can determine, that is should show change password notification.
2. Throw specific exception.
Maybe I am missing something in WS-Trust standard?
Im using WIF built-in implementation, so it is 1.3 version of standard with parts of 1.4.
Thanks a lot in advance.
WS-Trust 1.3 and 1.4 uses SOAP Fault mechanism. There are a handfull of faultcodes specified in the standard.
WS-Trust Error Handling
You can use wst:FailedAuthentication SOAP Fault code and provide second-level detail fields to explain password expired situation, but you should be careful not to introduce security vulnerabilities when doing so (e.g., by providing too detailed information).
I've done a little googling but have been a bit overwhelmed by the amount of information. Until now, I've been considering asking for a valid md5 hash for every API call but I realized that it wouldn't be a difficult task to hijack such a system. Would you guys be kind enough to provide me with a few links that might help me in my search? Thanks.
First, consider OAuth. It's somewhat of a standard for web-based APIs nowadays.
Second, some other potential resources -
A couple of decent blog entries:
http://blog.sonoasystems.com/detail/dont_roll_your_own_api_security_recommendations1/
http://blog.sonoasystems.com/detail/more_api_security_choices_oauth_ssl_saml_and_rolling_your_own/
A previous question:
Good approach for a web API token scheme?
I'd like to add some clarifying information to this question. The "use OAuth" answer is correct, but also loaded (given the spec is quite long and people who aren't familiar with it typically want to kill themselves after seeing it).
I wrote up a story-style tutorial on how to go from no security to HMAC-based security when designing a secure REST API here:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
This ends up being basically what is known as "2-legged OAuth"; because OAuth was originally intended to verifying client applications, the flow is 3-parts involving the authenticating service, the user staring at the screen and the service that wants to use the client's credentials.
2-legged OAuth (and what I outline in depth in that article) is intended for service APIs to authenticate between each other. For example, this is the approach Amazon Web Services uses for all their API calls.
The gist is that with any request over HTTP you have to consider the attack vector where some malicious man-in-the-middle is recording and replaying or changing your requests.
For example, you issue a POST to /user/create with name 'bob', well the man-in-the-middle can issue a POST to /user/delete with name 'bob' just to be nasty.
The client and server need some way to trust each other and the only way that can happen is via public/private keys.
You can't just pass the public/private keys back and forth NOR can you simply provide a unique token signed with the private key (which is typically what most people do and think that makes them safe), while that will identify the original request coming from the real client, it still leaves the arguments to the comment open to change.
For example, if I send:
/chargeCC?user=bob&amt=100.00&key=kjDSLKjdasdmiUDSkjh
where the key is my public key signed by my private key only a man-in-the-middle can intercept this call, and re-submit it to the server with an "amt" value of "10000.00" instead.
The key is that you have to include ALL the parameters you send in the hash calculation, so when the server gets it, it re-vets all the values by recalculating the same hash on its side.
REMINDER: Only the client and server know the private key.
This style of verification is called an "HMAC"; it is a checksum verifying the contents of the request.
Because hash generation is SO touchy and must be done EXACTLY the same on both the client and server in order to get the same hash, there are super-strict rules on exactly how all the values should be combined.
For example, these two lines provides VERY different hashes when you try and sign them with SHA-1:
/chargeCC&user=bob&amt=100
/chargeCC&amt=100&user=bob
A lot of the OAuth spec is spent describing that exact method of combination in excruciating detail, using terminology like "natural byte ordering" and other non-human-readable garbage.
It is important though, because if you get that combination of values wrong, the client and server cannot correctly vet each other's requests.
You also can't take shortcuts and just concatonate everything into a huge String, Amazon tried this with AWS Signature Version 1 and it turned out wrong.
I hope all of that helps, feel free to ask questions if you are stuck.
I want to log onto Stack Overflow using OpenID, but I thought I'd set up my own OpenID provider, just because it's harder :) How do you do this in Ubuntu?
Edit: Replacing 'server' with the correct term OpenID provider (Identity provider would also be correct according to wikipedia).
You might also look into setting up your own site as a delegate for another OpenID provider. That way, you can use your own custom URL, but not worry about security and maintenance as mentioned already. However, it's not very difficult, so it may not meet your criteria :)
As an example, you would add this snippet of HTML to the page at your desired OpenID URL if you are using ClaimID as the OpenID provider:
<link rel="openid.server" href="http://openid.claimid.com/server" />
<link rel="openid.delegate" href="http://openid.claimid.com/USERNAME" />
So when OpenID clients access your URL, they "redirect" themselves to the actual provider.
I've actually done this (set up my own server using phpMyID). It's very easy and works quite well. One thing that annoys me to no end is the use of HTML redirects instead of HTTP. I changed that manually, based on some information gotten in the phpMyID forum.
However, I have switched to myOpenId in the meantime. Rolling an own provider is fun and games but it just isn't secure! There are two issues:
More generally, you have to act on faith. phpMyID is great but it's developed in someone's spare time. There could be many undetected security holes in it – and there have been some, in the past. While this of course applies to all security-related software, I believe the problem is potentially more severe with software developed in spare time, especially since the code is far from perfect in my humble opinion.
Secondly, OpenID is highly susceptible to screen scraping and mock interfaces. It's just too easy for an attacker to emulate the phpMyID interface to obtain your credentials for another site. myOpenId offers two very important solutions to the problem.
The first is its use of a cookie-stored picture that is embedded in the login page. If anyone screen-scapes the myOpenId login page, this picture will be missing and the fake can easily be identified.
Secondly, myOpenId supports sign-in using strongly signed certificates that can be installed in the web browser.
I still have phpMyID set up as an alternative provider using Yadis but I wouldn't use it as a login on sites that I don't trust.
In any case, read Sam Ruby's tutorial!
I personnally used phpMyID just for StackOverflow. It's a simple two-files PHP script to put somewhere on a subdomain. Of course, it's not as easy as installing a .deb, but since OpenID relies completely on HTTP, I'm not sure it's advisable to install a self-contained server...
Take a look over at the Run your own identity server page. Community-ID looks to be the most promising so far.
I totally understand where you're coming from with this question. I already had a OpenID at www.myopenid.com but it feels a bit weird relying on a 3rd party for such an important login (a.k.a my permanent "home" on the internet).
Luckily, It is easy to move to using your own server as a openID server - in fact, it can be done with just two files with phpMyID.
Download "phpMyID-0.9.zip" from http://siege.org/projects/phpMyID/
Move it to your server and unzip it to view the README file which explains everything.
The zip has two files: MyID.config.php, MyID.php. I created a directory called <mydocumentroot>/OpenID and renamed MyID.config.php to index.php. This means my OpenID URL will be very cool: http://<mywebsite>/OpenID
Decide on a username and password and then create a hash of them using: echo -n '<myUserNam>:phpMyID:<myPassword>' | openssl md5
Open index.php in a text editor and add the username and password hash in the placeholder. Save it.
Test by browsing to http://<mywebsite>/OpenID/
Test ID is working using: http://www.openidenabled.com/resources/openid-test/checkup/
Rerefence info: http://www.wynia.org/wordpress/2007/01/15/setting-up-an-openid-with-php/ , http://siege.org/projects/phpMyID/ , https://blog.stackoverflow.com/2009/01/using-your-own-url-as-your-openid/
The above answers all seem to contains dead links.
This seems be a possible solution which is still working:
https://simpleid.org/