Showing posts with label Hacking. Show all posts
Showing posts with label Hacking. Show all posts

Friday, March 9, 2012

‘Not all hacking is bad or should be considered so’ - A conversation with Sumon Ahmed Sabir VP of ISPAB

Sumon Ahmed Sabir, vice president of Internet Service Providers Association of Bangladesh and a cyber security expert in Bangladesh, tells Saad Hammadi how the much hyped cyber warfare between India and Bangladesh was only a matter of generating propaganda on state-owned websites with no real security

Tell us your opinion about hacking in general.

Hacking had begun since the time computer networks emerged. However, those who are into hacking, some of them do it to show their technical skills and expertise and some are into committing financial crimes and other forms of online criminal offences. There is however, another dimension to hacking when it occurs with the state’s patronage.

Recently, Bangladesh and India have experienced intense cyber warfare among important websites being shut down by the opposition. Some IT professionals have said that this was not hacking but nuisance. What is the rationale?

I will not call it a cyber war. A lot of Bangladeshi websites were compromised just as much as the Indian websites. However, this is nothing new. The security features are vulnerable in most government owned websites. That is why a large portion of the websites hacked belong to the Bangladesh government. Not much of technical expertise is required to hack most of these websites which are very poorly coded. Skills and expertise are utilised when websites hacked are of professional standards.

I am not really interested whether it was a cyber war or not but that our websites are not secured is something we should be concerned about. We are not secured on websites and this is not to speak of Bangladesh only but all countries. There is no point over arguing on an area of cyber warfare just because we are not able to resolve an issue diplomatically which will only increase grievances.

Bangladesh’s virtual services and facilities are still at a developing stage, where not much of commercial transactions are performed. Given that Indian hackers often attack on Bangladeshi, how do you view the web security of the country’s important websites?

This time the incidents that occurred did not cause problem but we are gradually becoming IT enabled. When transaction-based websites will emerge in the country that is when we will be affected most. And this will happen sooner or later because hacking is a regular affair. We should be careful that we do not break down the same way in the future.

Right now you can check your bank balance or clear your credit card bills, which are limited only to your account and cannot be transferred to another. Hence, we are not becoming affected financially. Outside the country however, most people are affected because of financial losses.

However, because of poor security on our web servers, other countries are becoming affected. Hackers are using Bangladeshi servers as proxy or phishing sites to acquire passwords and usernames of prominent international banks and other e-commerce websites, which allow them to transfer money to their desired accounts. Just because we are not being affected, we are not being concerned. But such fraudulent websites are very common and we receive a lot of complaints from the CERTs (Computer Emergency Response Teams) of other countries.

While Bangladeshi hackers claimed to have shut down many Indian websites, Bangladesh was nonetheless exposed to similar attacks. Do you believe the ICT Act 2006 of Bangladesh require amendment to address such defacement and temporary deactivation of websites?

The intentions of attacking the websites on both ends were not aimed at damaging them. They only removed some contents, put some images, used cursive words or shut it down temporarily. There was no intention to cause financial damage. The attack was aimed at generating propaganda. However, I still cannot justify such a practice. The contents in our present ICT Act only protect us of local violations. Internet is something that goes beyond the territory. Hence, addressing online crimes is still a grey area. It could be someone sitting in the United States, using a computer server in India to initiate an attack on a Bangladeshi website. Under such circumstances, there is hardly enough evidence because the logs can be cleared. So, addressing the issue is still a very complicated process.

Even locally, if someone is found committing an offence, the penalty should be very carefully decided. Keeping someone behind bars for eight years for sending a threat email does not sound reasonable, which we have seen happen in the country in the past. It will however, not be right for me to talk on the legal area but laws should not be such that a minor offence entitles heavy punishment.

Will you share some of the security elements that Western countries maintain to contain such form of intrusion or hacking?

Whether developing countries or the West, we almost use the same security elements. Some organisations may be slight better but in general we all are vulnerable. This time the website hacking that took place, it was because the coding standards were weak. The website developers were not concerned with the security features while coding. The servers and software we are using, these are not timely upgraded and maintained. Thirdly, proper firewall rule sets are not maintained, which help to determine the level of access.

Some hackers are passionate about identifying bugs in reputed websites, something they enjoy doing and challenging. They say it helps them increase the efficiency of the website and helps them learn new things. Can skills of hackers be put to good use?

Those who have the technical efficiency, no doubt they are highly skilled. In many cases in the past we have seen hackers have come to the help of not just independent organisations but also states and governments. There are numerous examples. Not all hacking is bad or should be considered so. Somebody identifying a bug or informing the authority is a noble. Unless and until that bug is exploited to attack it is a good deed. The hacker word was a good term in the past. Right now the term itself gives a negative impression. In abroad, security analysts are hired to do the same task as hackers.

Source: New Age

Saturday, February 18, 2012

Protect Your Users Passwords without an Expensive SSL Certificate

Personal information security, one of the hottest topics on the lips of web professionals across the globe. How do we stop people not only hacking our sites and causing us inconvenience, but also how do we stop people accessing our users' personal information? Right now there is one major answer to these questions, SSL (secure socket layer). Proven technology which has fueled a boom in online transactions, allowing people to buy anything from dressing gowns to airplanes. However, SSL certificates can be costly to smaller web masters. These millions of people who offer a free service to the world hoping that their advertising may at least pay their hosting. Here is a small scale solution which can provide these people with an extra layer of security.

WARNING (Please Read)

This is a SMALL SCALE solution not intended for the communication of private information. This type of security should NOT be used on e-commerce applications or anything which deals with personal information of any kind. This is suitable only for small sites with log in areas which if compromised will not cause the leakage of valuable data.

How Can I Secure my Users Without SSL?

A large number of user on the web accounts which are compromised are the result of package sniffing. People who set up their servers to monitor packets which pass by for potentially valuable information. When using SSL this is not an issue since the encryption makes the data illegible to the sniffer but when using an open connection someone can easily pick up on an unencrypted user name and password. The key to SSL is that the data is encrypted before transport and we need to do that as regularly as we can. As web developers on the only client side resource available is JavaScript, executing on the users machine. We can use this (when enabled) to encrypt our data for us before it is sent to the server. Ofcourse this will only work when JavaScript is enabled but it is better that it is sometimes present rather than not there at all.

How Can I Implement this JavaScript Encryption?

You could argue that there are many ways to do this and this is only one. JavaScript does not have the likes of MD5 built in which can be used in other technologies to one-way encrypt data. However, it is possible to access it in the form of an user defined function. The best one I found for this was here : http://pajhome.org.uk/crypt/md5/index.html.

Once you have MD5 working on both server and client, you can use it to hash the password of your user when they submit the form just prior to it being posted in a HTTP request across the world. When your server receives this hashed password it can compare it to its records and authenticate it since you should be storing encrypted passwords anyway. Storing plain text passwords is EXTREMELY bad practice and should be avoided at all times. If someone were to hack your database your users would be in a whole lot of trouble and it would be all YOUR fault. People often use the same password on different sites so they could lose there account on more than just your website.

But How Do I Know if the Password has been Encrypted Client Side?

I see that there are two ways to do this. You can create a hidden input field in the DOM before submission, which when present in the post request can signify that JavaScript was enabled at the time of log in. There is also the alternative of limiting your users to passwords less than 32 characters (the length of an MD5 hash). This way you know if the password they submit is 32 characters long it has already been hashed.

Extra Server-side Security Pre-cautions

If a packet sniffer were to pick up on your newly hashed password and submit it themselves, they could easily bypass this new security making it pointless. To combat this I would recommend using time based hashing routines on the server to determine when the initial form was rendered, and timing that form out meaning it can not be submitted after a certain period of time. We can implement this by client-side hashing the password once, and then hashing it with a value given by the server concatenated on the end a second time. This value can be worked out by an algorithm on the server based on the time and can change every 5-10 minutes. At the server you can look up the users screen name in the database and hash their (already hashed) password with values which would still be valid to see if you can attain a match. If so, let them in, if not, ask them to try again. The packet sniffers could see this time based value sent by the server but if its ambiguous enough they will not be able to work out how it is calculated on the server, meaning they will have to be pretty quick to hack in.

Conclusion

There it is, user authentication encryption without a costly SSL certificate. I will re-iterate that this is not a proven solution, not all people will be able to use it since they may not have JavaScript which renders it useless. You must still offer a non-JavaScript solution which works the traditional way to meet standards and to offer your site to as many people as possible. Always remember that your users deserve you to look at ideas like this to protect them since us, the developers, are the ones who have control of this data and its up to us to do the best we can with it.

Feel free to comment below if you have any ideas which could develop this further, or maybe you have tried it and have a story to tell. Please, no people saying how it is insecure and isn't a viable option. I've stated many times that its not the securest encryption method out there and that this is not suitable for use with private data but it is cheap, easy and works where possible, which is better than transmitting plain text.

Source: Dev-Explorer


Implementing the JavaScript encryption method in ASP.NET

Download this JavaScript file JavascriptEncryption.
add the reference of this file to your project.
Now create a javascript function for encrypting a string :

function CryptPass() {
var pass=document.getElementById('txtpass').value;
document.getElementById('txtpass').value=hex_md5(pass);
}



Now call this function on the client click of the Submit or Login Button 


Now you need to Compare the MD5 hash in the Server Code 
For Example :
If you want to validate password="123456"
Then call the makeMD5Hash Function in the server code


VB.NET

If txtpass.text=makeMD5Hash("123456") Then
        'Login Success
End If

Function makeMD5Hash(ByVal strToHash as String) as String
Dim strToHash As String
        Dim md5Obj As New Security.Cryptography.MD5CryptoServiceProvider
        Dim bytesToHash() As Byte = System.Text.Encoding.ASCII.GetBytes(strToHash)
        bytesToHash = md5Obj.ComputeHash(bytesToHash)
        Dim strResult As String = ""
        For Each b As Byte In bytesToHash
            strResult += b.ToString("x2")
        Next
Return strResult
End Function



C#.NET

if (txtpass.text == makeMD5Hash("123456")) {
//Login Success


}
public string makeMD5Hash(string strToHash)
{
string strToHash = null;
System.Security.Cryptography.MD5CryptoServiceProvider md5Obj = new System.Security.Cryptography.MD5CryptoServiceProvider();
byte[] bytesToHash = System.Text.Encoding.ASCII.GetBytes(strToHash);
bytesToHash = md5Obj.ComputeHash(bytesToHash);
string strResult = "";
foreach (byte b in bytesToHash) {
strResult += b.ToString("x2");
}
return strResult;
}

Demo :



Friday, February 3, 2012

Anonymous intercept FBI and Scotland Yard phone call in which they discuss efforts against hacking

undefined

The conversation covers the tracking of Anonymous and other splinter groups, dates of planned arrests and details of evidence held by police. Anonymous also published an email from the FBI, showing the email addresses of call participants. The FBI confirmed the intercept and said it was hunting those responsible.





Source: AnonOps

Thursday, December 29, 2011

20 Indian Website Hacked by Team Cyber Turk Hacking

This summary is not available. Please click here to view the post.