Security with HTTPS and SSL

Security with HTTPS and SSL In this document Concepts An HTTP Example Common Problems Verifying Server Certificates Unknown certificate authority Self-signed server certificate Missing intermediate certificate authority Common Problems with Hostname Verification Warnings About Using SSLSocket Directly Blacklisting Pinning Client Certificates See also Android Security Overview Permissions The Secure Sockets Layer (SSL)—now technically known as Transport Layer Security (TLS)—is a common building block for encrypted communications between clients and servers. It's possible that an application might use SSL incorrectly such that malicious entities may be able to intercept an app's data over the network. To help you ensure that this does not happen to your app, this article highlights the common pitfalls when using secure network protocols and addresses some larger concerns about using Public-Key Infrastructure (PKI). Concepts In a typical SSL usage scenario, a server is configured with a certificate containing a public key as well as a matching private key. As part of the handshake between an SSL client and server, the server proves it has the private key by signing its certificate with public-key cryptography. However, anyone can generate their own certificate and private key, so a simple handshake doesn't prove anything about the server other than that the server knows the private key that matches the public key of the certificate. One way to solve this problem is to have the client have a set of one or more certificates it trusts. If the certificate is not in the set, the server is not to be trusted. There are several downsides to this simple approach. Servers should be able to upgrade to stronger keys over time ("key rotation"), which replaces the public key in the certificate with a new one. Unfortunately, now the client app has to be updated due to what is essentially a server configuration change. This is especially problematic if the server is not under the app developer's control, for example if it is a third party web service. This approach also has issues if the app has to talk to arbitrary servers such as a web browser or email app. In order to address these downsides, servers are typically configured with certificates from well known issuers called Certificate Authorities (CAs). The host platform generally contains a list of well known CAs that it trusts. As of Android 4.2 (Jelly Bean), Android currently contains over 100 CAs that are updated in each release. Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signs the server certificate using its private key. The client can then verify that the server has a certificate issued by a CA known to the platform. However, while solving some problems, using CAs introduces another. Because the CA issues certificates for many servers, you still need some way to make sure you are talking to the server you want. To address this, the certificate issued by the CA identifies the server either with a specific name such as gmail.com or a wildcarded set of hosts such as *.google.com. The following example will make these concepts a little more concrete. In the snippet below from a command line, the openssl tool's s_client command looks at Wikipedia's server certificate information. It specifies port 443 because that is the default for HTTPS. The command sends the output of openssl s_client to openssl x509, which formats information about certificates according to the X.509 standard. Specifically, the command asks for the subject, which contains the server name information, and the issuer, which identifies the CA. $ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA You can see that the certificate was issued for servers matching *.wikipedia.org by the RapidSSL CA. An HTTPS Example Assuming you have a web server with a certificate issued by a well known CA, you can make a secure request with code as simple this: URL url = new URL("https://wikipedia.org"); URLConnection urlConnection = url.openConnection(); InputStream in = urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); Yes, it really can be that simple. If you want to tailor the HTTP request, you can cast to an HttpURLConnection. The Android documentation for HttpURLConnection has further examples about how to deal with request and response headers, posting content, managing cookies, using proxies, caching responses, and so on. But in terms of the details for verifying certificates and hostnames, the Android framework takes care of it for you through these APIs. This is where you want to be if at all possible. That said, below are some other considerations. Common Problems Verifying Server Certificates Suppose instead of receiving the content from getInputStream(), it throws an exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374) at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209) at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478) at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433) at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290) at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240) at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282) at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177) at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271) This can happen for several reasons, including: The CA that issued the server certificate was unknown The server certificate wasn't signed by a CA, but was self signed The server configuration is missing an intermediate CA The following sections discuss how to address these problems while keeping your connection to the server secure. Unknown certificate authority In this case, the SSLHandshakeException occurs because you have a CA that isn't trusted by the system. It could be because you have a certificate from a new CA that isn't yet trusted by Android or your app is running on an older version without the CA. More often a CA is unknown because it isn't a public CA, but a private one issued by an organization such as a government, corporation, or education institution for their own use. Fortunately, you can teach HttpsURLConnection to trust a specific set of CAs. The procedure can be a little convoluted, so below is an example that takes a specific CA from an InputStream, uses it to create a KeyStore, which is then used to create and initialize a TrustManager. A TrustManager is what the system uses to validate certificates from the server and—by creating one from a KeyStore with one or more CAs—those will be the only CAs trusted by that TrustManager. Given the new TrustManager, the example initializes a new SSLContext which provides an SSLSocketFactory you can use to override the default SSLSocketFactory from HttpsURLConnection. This way the connection will use your CAs for certificate validation. Here is the example in full using an organizational CA from the University of Washington: // Load CAs from an InputStream // (could be from a resource or ByteArrayInputStream or ...) CertificateFactory cf = CertificateFactory.getInstance("X.509"); // From https://www.washington.edu/itconnect/security/ca/load-der.crt InputStream caInput = new BufferedInputStream(new FileInputStream("load-der.crt")); Certificate ca; try { ca = cf.generateCertificate(caInput); System.out.println("ca=" + ((X509Certificate) ca).getSubjectDN()); } finally { caInput.close(); } // Create a KeyStore containing our trusted CAs String keyStoreType = KeyStore.getDefaultType(); KeyStore keyStore = KeyStore.getInstance(keyStoreType); keyStore.load(null, null); keyStore.setCertificateEntry("ca", ca); // Create a TrustManager that trusts the CAs in our KeyStore String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(tmfAlgorithm); tmf.init(keyStore); // Create an SSLContext that uses our TrustManager SSLContext context = SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManagers(), null); // Tell the URLConnection to use a SocketFactory from our SSLContext URL url = new URL("https://certs.cac.washington.edu/CAtest/"); HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection(); urlConnection.setSSLSocketFactory(context.getSocketFactory()); InputStream in = urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); With a custom TrustManager that knows about your CAs, the system is able to validate that your server certificate come from a trusted issuer. Caution: Many web sites describe a poor alternative solution which is to install a TrustManager that does nothing. If you do this you might as well not be encrypting your communication, because anyone can attack your users at a public Wi-Fi hotspot by using DNS tricks to send your users' traffic through a proxy of their own that pretends to be your server. The attacker can then record passwords and other personal data. This works because the attacker can generate a certificate and—without a TrustManager that actually validates that the certificate comes from a trusted source—your app could be talking to anyone. So don't do this, not even temporarily. You can always make your app trust the issuer of the server's certificate, so just do it. Self-signed server certificate The second case of SSLHandshakeException is due to a self-signed certificate, which means the server is behaving as its own CA. This is similar to an unknown certificate authority, so you can use the same approach from the previous section. You can create your own TrustManager, this time trusting the server certificate directly. This has all of the downsides discussed earlier of tying your app directly to a certificate, but can be done securely. However, you should be careful to make sure your self-signed certificate has a reasonably strong key. As of 2012, a 2048-bit RSA signature with an exponent of 65537 expiring yearly is acceptable. When rotating keys, you should check for recommendations from an authority (such as NIST) about what is acceptable. Missing intermediate certificate authority The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don't sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise. However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate—signed by the intermediate CA—and the certificate verifier, which knows the root CA. To solve this, the server doesn't send the client only it's certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA. To see what this looks like in practice, here's the mail.google.com certificate chain as viewed by the openssl s_client command: $ openssl s_client -connect mail.google.com:443 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- This shows that the server sends a certificate for mail.google.com issued by the Thawte SGC CA, which is an intermediate CA, and a second certificate for the Thawte SGC CA issued by a Verisign CA, which is the primary CA that's trusted by Android. However, it is not uncommon to configure a server to not include the necessary intermediate CA. For example, here is a server that can cause an error in Android browsers and exceptions in Android apps: $ openssl s_client -connect egov.uscis.gov:443 --- Certificate chain 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3 --- What is interesting to note here is that visiting this server in most desktop browsers does not cause an error like a completely unknown CA or self-signed server certificate would cause. This is because most desktop browsers cache trusted intermediate CAs over time. Once a browser has visited and learned about an intermediate CA from one site, it won't need to have the intermediate CA included in the certificate chain the next time. Some sites do this intentionally for secondary web servers used to serve resources. For example, they might have their main HTML page served by a server with a full certificate chain, but have servers for resources such as images, CSS, or JavaScript not include the CA, presumably to save bandwidth. Unfortunately, sometimes these servers might be providing a web service you are trying to call from your Android app, which is not as forgiving. There are two approaches to solve this issue: Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2. Or, treat the intermediate CA like any other unknown CA, and create a TrustManager to trust it directly, as done in the previous two sections. Common Problems with Hostname Verification As mentioned at the beginning of this article, there are two key parts to verifying an SSL connection. The first is to verify the certificate is from a trusted source, which was the focus of the previous section. The focus of this section is the second part: making sure the server you are talking to presents the right certificate. When it doesn't, you'll typically see an error like this: java.io.IOException: Hostname 'example.com' was not verified at libcore.net.http.HttpConnection.verifySecureSocketHostname(HttpConnection.java:223) at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:446) at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290) at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240) at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282) at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177) at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271) One reason this can happen is due to a server configuration error. The server is configured with a certificate that does not have a subject or subject alternative name fields that match the server you are trying to reach. It is possible to have one certificate be used with many different servers. For example, looking at the google.com certificate with openssl s_client -connect google.com:443 | openssl x509 -text you can see that a subject that supports *.google.com but also subject alternative names for *.youtube.com, *.android.com, and others. The error occurs only when the server name you are connecting to isn't listed by the certificate as acceptable. Unfortunately this can happen for another reason as well: virtual hosting. When sharing a server for more than one hostname with HTTP, the web server can tell from the HTTP/1.1 request which target hostname the client is looking for. Unfortunately this is complicated with HTTPS, because the server has to know which certificate to return before it sees the HTTP request. To address this problem, newer versions of SSL, specifically TLSv.1.0 and later, support Server Name Indication (SNI), which allows the SSL client to specify the intended hostname to the server so the proper certificate can be returned. Fortunately, HttpsURLConnection supports SNI since Android 2.3. Unfortunately, Apache HTTP Client does not, which is one of the many reasons we discourage its use. One workaround if you need to support Android 2.2 (and older) or Apache HTTP Client is to set up an alternative virtual host on a unique port so that it's unambiguous which server certificate to return. The more drastic alternative is to replace HostnameVerifier with one that uses not the hostname of your virtual host, but the one returned by the server by default. Caution: Replacing HostnameVerifier can be very dangerous if the other virtual host is not under your control, because a man-in-the-middle attack could direct traffic to another server without your knowledge. If you are still sure you want to override hostname verification, here is an example that replaces the verifier for a single URLConnection with one that still verifies that the hostname is at least on expected by the app: // Create an HostnameVerifier that hardwires the expected hostname. // Note that is different than the URL's hostname: // example.com versus example.org HostnameVerifier hostnameVerifier = new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier(); return hv.verify("example.com", session); } }; // Tell the URLConnection to use our HostnameVerifier URL url = new URL("https://example.org/"); HttpsURLConnection urlConnection = (HttpsURLConnection)url.openConnection(); urlConnection.setHostnameVerifier(hostnameVerifier); InputStream in = urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out); But remember, if you find yourself replacing hostname verification, especially due to virtual hosting, it's still very dangerous if the other virtual host is not under your control and you should find an alternative hosting arrangement that avoids this issue. Warnings About Using SSLSocket Directly So far, the examples have focused on HTTPS using HttpsURLConnection. Sometimes apps need to use SSL separate from HTTP. For example, an email app might use SSL variants of SMTP, POP3, or IMAP. In those cases, the app would want to use SSLSocket directly, much the same way that HttpsURLConnection does internally. The techniques described so far to deal with certificate verification issues also apply to SSLSocket. In fact, when using a custom TrustManager, what is passed to HttpsURLConnection is an SSLSocketFactory. So if you need to use a custom TrustManager with an SSLSocket, follow the same steps and use that SSLSocketFactory to create your SSLSocket. Caution: SSLSocket does not perform hostname verification. It is up the your app to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further beware that HostnameVerifier.verify() doesn't throw an exception on error but instead returns a boolean result that you must explicitly check. Here is an example showing how you can do this. It shows that when connecting to gmail.com port 443 without SNI support, you'll receive a certificate for mail.google.com. This is expected in this case, so check to make sure that the certificate is indeed for mail.google.com: // Open SSLSocket directly to gmail.com SocketFactory sf = SSLSocketFactory.getDefault(); SSLSocket socket = (SSLSocket) sf.createSocket("gmail.com", 443); HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier(); SSLSession s = socket.getSession(); // Verify that the certicate hostname is for mail.google.com // This is due to lack of SNI support in the current SSLSocket. if (!hv.verify("mail.google.com", s)) { throw new SSLHandshakeException("Expected mail.google.com, " "found " + s.getPeerPrincipal()); } // At this point SSLSocket performed certificate verificaiton and // we have performed hostname verification, so it is safe to proceed. // ... use socket ... socket.close(); Blacklisting SSL relies heavily on CAs to issue certificates to only the properly verified owners of servers and domains. In rare cases, CAs are either tricked or, in the case of Comodo or DigiNotar, breached, resulting in the certificates for a hostname to be issued to someone other than the owner of the server or domain. In order to mitigate this risk, Android has the ability to blacklist certain certificates or even whole CAs. While this list was historically built into the operating system, starting in Android 4.2 this list can be remotely updated to deal with future compromises. Pinning An app can further protect itself from fraudulently issued certificates by a technique known as pinning. This is basically using the example provided in the unknown CA case above to restrict an app's trusted CAs to a small set known to be used by the app's servers. This prevents the compromise of one of the other 100+ CAs in the system from resulting in a breach of the apps secure channel. Client Certificates This article has focused on the user of SSL to secure communications with servers. SSL also supports the notion of client certificates that allow the server to validate the identity of a client. While beyond the scope of this article, the techniques involved are similar to specifying a custom TrustManager. See the discussion about creating a custom KeyManager in the documentation for HttpsURLConnection. We are recomanded publishes some of the highest quality games available online, all completely free to play. Our massive selection of games include some of the most played genres online, the most popular being racing games, puzzle games, action games, MMO games and many more, all guaranteed to keep you entertained for hours to come. y8 | agame | friv | y3 | kizi | barbie | friv | y8 | huz | y8 | ben 10 | online games | miniclip | y8 | y8 | addicting games | y3 | y8 | funbrain | agame | y8 | friv | y3 | y8 | miniclip | friv | barbie | yepi | y8 | free games |y8 | addicting games | friv | all sites guaranteed to keep you entertained for hours to come.

Android Security Tips

Security Tips In this document Storing Data Using Permissions Using Networking Performing Input Validation Handling User Data Using WebView Using Cryptography Using Interprocess Communication Dynamically Loading Code Security in a Virtual Machine Security in Native Code See also Android Security Overview Permissions Android has security features built into the operating system that significantly reduce the frequency and impact of application security issues. The system is designed so you can typically build your apps with default system and file permissions and avoid difficult decisions about security. Some of the core security features that help you build secure apps include: The Android Application Sandbox, which isolates your app data and code execution from other apps. An application framework with robust implementations of common security functionality such as cryptography, permissions, and secure IPC. Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks associated with common memory management errors. An encrypted filesystem that can be enabled to protect data on lost or stolen devices. User-granted permissions to restrict access to system features and user data. Application-defined permissions to control application data on a per-app basis. Nevertheless, it is important that you be familiar with the Android security best practices in this document. Following these practices as general coding habits will reduce the likelihood of inadvertently introducing security issues that adversely affect your users. Storing Data The most common security concern for an application on Android is whether the data that you save on the device is accessible to other apps. There are three fundamental ways to save data on the device: Using internal storage By default, files that you create on internal storage are accessible only to your app. This protection is implemented by Android and is sufficient for most applications. You should generally avoid using the MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE modes for IPC files because they do not provide the ability to limit data access to particular applications, nor do they provide any control on data format. If you want to share your data with other app processes, you might instead consider using a content provider, which offers read and write permissions to other apps and can make dynamic permission grants on a case-by-case basis. To provide additional protection for sensitive data, you might choose to encrypt local files using a key that is not directly accessible to the application. For example, a key can be placed in a KeyStore and protected with a user password that is not stored on the device. While this does not protect data from a root compromise that can monitor the user inputting the password, it can provide protection for a lost device without file system encryption. Using external storage Files created on external storage, such as SD Cards, are globally readable and writable. Because external storage can be removed by the user and also modified by any application, you should not store sensitive information using external storage. As with data from any untrusted source, you should perform input validation when handling data from external storage. We strongly recommend that you not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading. Using content providers Content providers offer a structured storage mechanism that can be limited to your own application or exported to allow access by other applications. If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false in the application manifest. Otherwise, set the android:exported attribute "true" to allow other apps to access the stored data. When creating a ContentProvider that will be exported for use by other applications, you can specify a single permission for reading and writing, or distinct permissions for reading and writing within the manifest. We recommend that you limit your permissions to those required to accomplish the task at hand. Keep in mind that it’s usually easier to add permissions later to expose new functionality than it is to take them away and break existing users. If you are using a content provider for sharing data between only your own apps, it is preferable to use the android:protectionLevel attribute set to "signature" protection. Signature permissions do not require user confirmation, so they provide a better user experience and more controlled access to the content provider data when the apps accessing the data are signed with the same key. Content providers can also provide more granular access by declaring the android:grantUriPermissions attribute and using the FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags in the Intent object that activates the component. The scope of these permissions can be further limited by the . When accessing a content provider, use parameterized query methods such as query(), update(), and delete() to avoid potential SQL injection from untrusted sources. Note that using parameterized methods is not sufficient if the selection argument is built by concatenating user data prior to submitting it to the method. Do not have a false sense of security about the write permission. Consider that the write permission allows SQL statements which make it possible for some data to be confirmed using creative WHERE clauses and parsing the results. For example, an attacker might probe for presence of a specific phone number in a call-log by modifying a row only if that phone number already exists. If the content provider data has predictable structure, the write permission may be equivalent to providing both reading and writing. Using Permissions Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox, including access to device features such as the camera. Requesting Permissions We recommend minimizing the number of permissions that your app requests. Not having access to sensitive permissions reduces the risk of inadvertently misusing those permissions, can improve user adoption, and makes your app less vulnerable for attackers. Generally, if a permission is not required for your app to function, do not request it. If it's possible to design your application in a way that does not require any permissions, that is preferable. For example, rather than requesting access to device information to create a unique identifier, create a GUID for your application (see the section about Handling User Data). Or, rather than using external storage (which requires permission), store data on the internal storage. In addition to requesting permissions, your application can use the to protect IPC that is security sensitive and will be exposed to other applications, such as a ContentProvider. In general, we recommend using access controls other than user confirmed permissions where possible because permissions can be confusing for users. For example, consider using the signature protection level on permissions for IPC communication between applications provided by a single developer. Do not leak permission-protected data. This occurs when your app exposes data over IPC that is only available because it has a specific permission, but does not require that permission of any clients of it’s IPC interface. More details on the potential impacts, and frequency of this type of problem is provided in this research paper published at USENIX: http://www.cs.be rkeley.edu/~afelt/felt_usenixsec2011.pdf Creating Permissions Generally, you should strive to define as few permissions as possible while satisfying your security requirements. Creating a new permission is relatively uncommon for most applications, because the system-defined permissions cover many situations. Where appropriate, perform access checks using existing permissions. If you must create a new permission, consider whether you can accomplish your task with a "signature" protection level. Signature permissions are transparent to the user and only allow access by applications signed by the same developer as application performing the permission check. If you create a permission with the "dangerous" protection level, there are a number of complexities that you need to consider: The permission must have a string that concisely expresses to a user the security decision they will be required to make. The permission string must be localized to many different languages. Users may choose not to install an application because a permission is confusing or perceived as risky. Applications may request the permission when the creator of the permission has not been installed. Each of these poses a significant non-technical challenge for you as the developer while also confusing your users, which is why we discourage the use of the "dangerous" permission level. Using Networking Network transactions are inherently risky for security, because it involves transmitting data that is potentially private to the user. People are increasingly aware of the privacy concerns of a mobile device, especially when the device performs network transactions, so it's very important that your app implement all best practices toward keeping the user's data secure at all times. Using IP Networking Networking on Android is not significantly different from other Linux environments. The key consideration is making sure that appropriate protocols are used for sensitive data, such as HttpsURLConnection for secure web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is supported on the server, because mobile devices frequently connect on networks that are not secured, such as public Wi-Fi hotspots. Authenticated, encrypted socket-level communication can be easily implemented using the SSLSocket class. Given the frequency with which Android devices connect to unsecured wireless networks using Wi-Fi, the use of secure networking is strongly encouraged for all applications that communicate over the network. We have seen some applications use localhost network ports for handling sensitive IPC. We discourage this approach since these interfaces are accessible by other applications on the device. Instead, you should use an Android IPC mechanism where authentication is possible such as with a Service. (Even worse than using loopback is to bind to INADDR_ANY since then your application may receive requests from anywhere.) Also, one common issue that warrants repeating is to make sure that you do not trust data downloaded from HTTP or other insecure protocols. This includes validation of input in WebView and any responses to intents issued against HTTP. Using Telephony Networking The SMS protocol was primarily designed for user-to-user communication and is not well-suited for apps that want to transfer data. Due to the limitations of SMS, we strongly recommend the use of Google Cloud Messaging (GCM) and IP networking for sending data messages from a web server to your app on a user device. Beware that SMS is neither encrypted nor strongly authenticated on either the network or the device. In particular, any SMS receiver should expect that a malicious user may have sent the SMS to your application—Do not rely on unauthenticated SMS data to perform sensitive commands. Also, you should be aware that SMS may be subject to spoofing and/or interception on the network. On the Android-powered device itself, SMS messages are transmitted as broadcast intents, so they may be read or captured by other applications that have the READ_SMS permission. Performing Input Validation Insufficient input validation is one of the most common security problems affecting applications, regardless of what platform they run on. Android does have platform-level countermeasures that reduce the exposure of applications to input validation issues and you should use those features where possible. Also note that selection of type-safe languages tends to reduce the likelihood of input validation issues. If you are using native code, then any data read from files, received over the network, or received from an IPC has the potential to introduce a security issue. The most common problems are buffer overflows, use after free, and off-by-one errors. Android provides a number of technologies like ASLR and DEP that reduce the exploitability of these errors, but they do not solve the underlying problem. You can prevent these vulneratbilities by careful handling pointers and managing buffers. Dynamic, string based languages such as JavaScript and SQL are also subject to input validation problems due to escape characters and script injection. If you are using data within queries that are submitted to an SQL database or a content provider, SQL injection may be an issue. The best defense is to use parameterized queries, as is discussed in the above section about content providers. Limiting permissions to read-only or write-only can also reduce the potential for harm related to SQL injection. If you cannot use the security features above, we strongly recommend the use of well-structured data formats and verifying that the data conforms to the expected format. While blacklisting of characters or character-replacement can be an effective strategy, these techniques are error-prone in practice and should be avoided when possible. Handling User Data In general, the best approach for user data security is to minimize the use of APIs that access sensitive or personal user data. If you have access to user data and can avoid storing or transmitting the information, do not store or transmit the data. Finally, consider if there is a way that your application logic can be implemented using a hash or non-reversible form of the data. For example, your application might use the hash of an an email address as a primary key, to avoid transmitting or storing the email address. This reduces the chances of inadvertently exposing data, and it also reduces the chance of attackers attempting to exploit your application. If your application accesses personal information such as passwords or usernames, keep in mind that some jurisdictions may require you to provide a privacy policy explaining your use and storage of that data. So following the security best practice of minimizing access to user data may also simplify compliance. You should also consider whether your application might be inadvertently exposing personal information to other parties such as third-party components for advertising or third-party services used by your application. If you don't know why a component or service requires a personal information, don’t provide it. In general, reducing the access to personal information by your application will reduce the potential for problems in this area. If access to sensitive data is required, evaluate whether that information must be transmitted to a server, or whether the operation can be performed on the client. Consider running any code using sensitive data on the client to avoid transmitting user data. Also, make sure that you do not inadvertently expose user data to other application on the device through overly permissive IPC, world writable files, or network sockets. This is a special case of leaking permission-protected data, discussed in the Requesting Permissions section. If a GUID is required, create a large, unique number and store it. Do not use phone identifiers such as the phone number or IMEI which may be associated with personal information. This topic is discussed in more detail in the Android Developer Blog. Be careful when writing to on-device logs. In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission. Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications. Using WebView Because WebView consumes web content that can include HTML and JavaScript, improper use can introduce common web security issues such as cross-site-scripting (JavaScript injection). Android includes a number of mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application. If your application does not directly use JavaScript within a WebView, do not call setJavaScriptEnabled(). Some sample code uses this method, which you might repurpose in production application, so remove that method call if it's not required. By default, WebView does not execute JavaScript so cross-site-scripting is not possible. Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. If you use it, expose addJavaScriptInterface() only to web pages from which all input is trustworthy. If untrusted input is allowed, untrusted JavaScript may be able to invoke Android methods within your app. In general, we recommend exposing addJavaScriptInterface() only to JavaScript that is contained within your application APK. If your application accesses sensitive data with a WebView, you may want to use the clearCache() method to delete any files stored locally. Server-side headers like no-cache can also be used to indicate that an application should not cache particular content. Handling Credentials In general, we recommend minimizing the frequency of asking for user credentials—to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it. Where possible, username and password should not be stored on the device. Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token. Services that will be accessible to multiple applications should be accessed using AccountManager. If possible, use the AccountManager class to invoke a cloud-based service and do not store passwords on the device. After using AccountManager to retrieve an Account, CREATOR before passing in any credentials, so that you do not inadvertently pass credentials to the wrong application. If credentials are to be used only by applications that you create, then you can verify the application which accesses the AccountManager using checkSignature(). Alternatively, if only one application will use the credential, you might use a KeyStore for storage. Using Cryptography In addition to providing data isolation, supporting full-filesystem encryption, and providing secure communications channels, Android provides a wide array of algorithms for protecting data using cryptography. In general, try to use the highest level of pre-existing framework implementation that can support your use case. If you need to securely retrieve a file from a known location, a simple HTTPS URI may be adequate and requires no knowledge of cryptography. If you need a secure tunnel, consider using HttpsURLConnection or SSLSocket, rather than writing your own protocol. If you do find yourself needing to implement your own protocol, we strongly recommend that you not implement your own cryptographic algorithms. Use existing cryptographic algorithms such as those in the implementation of AES or RSA provided in the Cipher class. Use a secure random number generator, SecureRandom, to initialize any cryptographic keys, KeyGenerator. Use of a key that is not generated with a secure random number generator significantly weakens the strength of the algorithm, and may allow offline attacks. If you need to store a key for repeated use, use a mechanism like KeyStore that provides a mechanism for long term storage and retrieval of cryptographic keys. Using Interprocess Communication Some apps attempt to implement IPC using traditional Linux techniques such as network sockets and shared files. We strongly encourage you to instead use Android system functionality for IPC such as Intent, Binder or Messenger with a Service, and BroadcastReceiver. The Android IPC mechanisms allow you to verify the identity of the application connecting to your IPC and set security policy for each IPC mechanism. Many of the security elements are shared across IPC mechanisms. If your IPC mechanism is not intended for use by other applications, set the android:exported attribute to "false" in the component's manifest element, such as for the element. This is useful for applications that consist of multiple processes within the same UID, or if you decide late in development that you do not actually want to expose functionality as IPC but you don’t want to rewrite the code. If your IPC is intended to be accessible to other applications, you can apply a security policy by using the element. If IPC is between your own separate apps that are signed with the same key, it is preferable to use "signature" level permission in the android:protectionLevel. Using intents Intents are the preferred mechanism for asynchronous IPC in Android. Depending on your application requirements, you might use sendBroadcast(), sendOrderedBroadcast(), or an explicit intent to a specific application component. Note that ordered broadcasts can be “consumed” by a recipient, so they may not be delivered to all applications. If you are sending an intent that must be delivered to a specific receiver, then you must use an explicit intent that declares the receiver by nameintent. Senders of an intent can verify that the recipient has a permission specifying a non-Null permission with the method call. Only applications with that permission will receive the intent. If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications cannot register to receive those messages without appropriate permissions. In those circumstances, you may also consider invoking the receiver directly, rather than raising a broadcast. Note: Intent filters should not be considered a security feature—components can be invoked with explicit intents and may not have data that would conform to the intent filter. You should perform input validation within your intent receiver to confirm that it is properly formatted for the invoked receiver, service, or activity. Using services A Service is often used to supply functionality for other applications to use. Each service class must have a corresponding declaration in its manifest file. By default, services are not exported and cannot be invoked by any other application. However, if you add any intent filters to the service declaration, then it is exported by default. It's best if you explicitly declare the android:exported attribute to be sure it behaves as you'd like. Services can also be protected using the android:permission attribute. By doing so, other applications will need to declare a corresponding element in their own manifest to be able to start, stop, or bind to the service. A service can protect individual IPC calls into it with permissions, by calling checkCallingPermission() before executing the implementation of that call. We generally recommend using the declarative permissions in the manifest, since those are less prone to oversight. Using binder and messenger interfaces Using Binder or Messenger is the preferred mechanism for RPC-style IPC in Android. They provide a well-defined interface that enables mutual authentication of the endpoints, if required. We strongly encourage designing interfaces in a manner that does not require interface specific permission checks. Binder and Messenger objects are not declared within the application manifest, and therefore you cannot apply declarative permissions directly to them. They generally inherit permissions declared in the application manifest for the Service or Activity within which they are implemented. If you are creating an interface that requires authentication and/or access controls, those controls must be explicitly added as code in the Binder or Messenger interface. If providing an interface that does require access controls, use checkCallingPermission() to verify whether the caller has a required permission. This is especially important before accessing a service on behalf of the caller, as the identify of your application is passed to other interfaces. If invoking an interface provided by a Service, the bindService() invocation may fail if you do not have permission to access the given service. If calling an interface provided locally by your own application, it may be useful to use the clearCallingIdentity() to satisfy internal security checks. For more information about performing IPC with a service, see Bound Services. Using broadcast receivers A BroadcastReceiver handles asynchronous requests initiated by an Intent. By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver is intended for use by other applications, you may want to apply security permissions to receivers using the element within the application manifest. This will prevent applications without appropriate permissions from sending an intent to the BroadcastReceiver. Dynamically Loading Code We strongly discourage loading code from outside of your application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management and application testing. Finally, it can make it impossible to verify the behavior of an application, so it may be prohibited in some environments. If your application does dynamically load code, the most important thing to keep in mind about dynamically loaded code is that it runs with the same security permissions as the application APK. The user made a decision to install your application based on your identity, and they are expecting that you provide any code run within the application, including code that is dynamically loaded. The major security risk associated with dynamically loading code is that the code needs to come from a verifiable source. If the modules are included directly within your APK, then they cannot be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader. We have seen many instances of applications attempting to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world writable locations such as external storage. These locations could allow someone on the network to modify the content in transit, or another application on a users device to modify the content on the device, respectively. Security in a Virtual Machine Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android, but many of the concerns regarding secure code in other virtual machines also apply to Android. In general, you shouldn't concern yourself with security issues relating to the virtual machine. Your application runs in a secure sandbox environment, so other processes on the system cannnot access your code or private data. If you're interested in diving deeper on the subject of virtual machine security, we recommend that you familiarize yourself with some existing literature on the subject. Two of the more popular resources are: http://www.securingjava.com/toc.html https://www.owasp.org/index.php/Java_Security_Resources This document is focused on the areas which are Android specific or different from other VM environments. For developers experienced with VM programming in other environments, there are two broad issues that may be different about writing apps for Android: Some virtual machines, such as the JVM or .net runtime, act as a security boundary, isolating code from the underlying operating system capabilities. On Android, the Dalvik VM is not a security boundary—the application sandbox is implemented at the OS level, so Dalvik can interoperate with native code in the same application without any security constraints. Given the limited storage on mobile devices, it’s common for developers to want to build modular applications and use dynamic class loading. When doing this, consider both the source where you retrieve your application logic and where you store it locally. Do not use dynamic class loading from sources that are not verified, such as unsecured network sources or external storage, because that code might be modified to include malicious behavior. Security in Native Code In general, we encourage developers to use the Android SDK for application development, rather than using native code with the Android NDK. Applications built with native code are more complex, less portable, and more like to include common memory corruption errors such as buffer overflows. Android is built using the Linux kernel and being familiar with Linux development security best practices is especially useful if you are going to use native code. Linux security practices are beyond the scope of this document, but one of the most popular resources is “Secure Programming for Linux and Unix HOWTO”, available at http://www.dwheeler.com/secure-programs. An important difference between Android and most Linux environments is the Application Sandbox. On Android, all applications run in the Application Sandbox, including those written with native code. At the most basic level, a good way to think about it for developers familiar with Linux is to know that every application is given a unique UID with very limited permissions. This is discussed in more detail in the Android Security Overview and you should be familiar with application permissions even if you are using native code. We are recomanded publishes some of the highest quality games available online, all completely free to play. Our massive selection of games include some of the most played genres online, the most popular being racing games, puzzle games, action games, MMO games and many more, all guaranteed to keep you entertained for hours to come. y8 | agame | friv | y3 | kizi | barbie | friv | y8 | huz | y8 | ben 10 | online games | miniclip | y8 | y8 | addicting games | y3 | y8 | funbrain | agame | y8 | friv | y3 | y8 | miniclip | friv | barbie | yepi | y8 | free games |y8 | addicting games | friv | all sites guaranteed to keep you entertained for hours to come.

Businesses Beefing Up on IT Security Specialists

In the wake of increased high-profile cybersecurity breaches, new research shows businesses are beefing up on their IT security specialists. The 2012 Career Impact study by (ISC)2, a nonprofit organization representing security specialists worldwide, found that 72 percent of businesses hired new employees last year specifically for their information security skills. Sixty-two percent of businesses reported they are looking to hire additional information security employees in 2012. "This data reflects the increase in security breaches we saw throughout 2011 and the fact that organizations, both in the public and private sector, are finally realizing the importance of implementing sound security programs that should be run by experienced and qualified professionals," said W. Hord Tipton, executive director of (ISC)². "Even in tough economic times, information security professionals are in high demand by hiring managers and organizations who understand that their skill sets are not only paramount to their organization's ability to conduct business, but also give them a competitive advantage." As demand for IT security specialists increases, the research shows many organizations are doing more to reward the qualified employees they already have on staff. Nearly 70 percent of those surveyed received a salary increase in 2011, with 55 percent expecting another raise in 2012. "While it’s a very positive sign that this field continues to grow and is somewhat 'recession-proof,' one of the biggest challenges that remains is finding enough of the right people with the appropriate security skills to fill the huge void that exists right now," Tipton said. "We must continue to build this workforce at an aggressive pace." The study shows the top skills hiring managers are looking for include operations security, security management practices, access control systems/methodology, security architecture/models, risk management, telecom/network security, applications/system development security and cloud/virtualization. The research was based on surveys of more than 2,200 security specialists from around the world.

Set to Be Worst Year Ever for Security Breaches

Sony, the data-security firm RSA, Lockheed Martin, the email wholesaler Epsilon, the Fox broadcast network, NASA, PBS, the European Space Agency, the FBI, the British and French treasuries — and, just this morning, the banking and insurance giant Citigroup. What do all these organizations have in common? Along with dozens of other companies and government agencies, they were victims of massive network security breaches in the first six months of this year. "In the last 10 years, I don't think we've seen breaches that have affected consumers at this scale," said Ondrej Krehel, information security officer for Scottsdale, Ariz.-based Identity Theft 911. "It's been the worst year in a decade." [Behind the Cybercrime Surge: Smarts, Laziness and Cool] Tim Armstrong, malware researcher for the Russian security firm Kaspersky Lab, agreed. "It's only June," Armstrong said, "but it has already [been an] impressive year for breaches." Sony, RSA and Epsilon usher in the season The worst three cybersecurity incidents of the year so far have involved RSA, Epsilon and Sony. In mid-March, Boston-based cryptography firm RSA suffered a massive network intrusion that resulted in the theft of information related to its SecurID tokens. Forty million people use the tokens to access the internal computer networks of 25,000 corporations, government organizations and financial institutions. Two months later, defense contractor Lockheed Martin had its own networks penetrated by attackers who used "cloned" RSA tokens made with data taken in the original breach.Unconfirmed reports named defense contractors Northrop Grumman and L-3 Communications as other victims. In early April, hackers penetrated the internal networks of Epsilon, a Texas-based firm that handles email communications for more than 2,500 clients worldwide. The companies affected by the Epsilon hack included Ameriprise Financial, BestBuy, Capital One Bank, Citi, JPMorgan Chase, TiVo, U.S. Bank and dozens more. Last (but not least in the eyes of some gamers) is Sony. Since early April, the Japanese entertainment and electronics giant has been fighting different groups of hackers. One group stole the personal information of 102 million registered users of the PlayStation Network (PSN) and other online gaming services. "I believe that the PSN breach has made it [penetrating a network] somewhat fashionable," Armstrong said. "Despite the obvious negative implications, the recent compromises have a 'hacktivism' ring to them that engenders support and even motivates some that may not normally cross the line." Who else has been hacked? Other organizations who've had their security compromised in 2011 include NASA's Goddard Space Flight Center, which lost confidential satellite data in an April hack, and InfraGard, an FBI affiliate that was compromised by the hacking group LulzSec, which also attacked PBS, Nintendo and Fox. To this list we can also add the European Commission, blogging platform WordPress, the Institute of Electrical and Electronics Engineers (IEEE), TripAdvisor, Gawker Media, speed trap warning service Trapster and the Pentagon's official credit union. Chet Wisniewski, senior security advisor with the security firm Sophos, suggested that major companies, especially ones that store large amounts of sensitive consumer data on their networks, simply aren't taking security seriously enough. That lax attitude, coupled with cybercriminals who are technologically savvy enough to perform sophisticated network intrusions, has made 2011 a year dozens of major companies will remember — and hopefully never repeat. Where do we go from here? The security forecast for the rest of the year, security experts say, is not looking too sunny. "I see the trend getting worse," Armstrong said. "Due to the lax security posture of many large-scale global companies, it has now become almost trivial for a motivated group or individual to find a way in. "Add to that the potential of gaining huge amounts of valuable information, and I think we see a trend that can only grow until companies finally make more effort." "It's not over yet," Wisniewski said. Although these sophisticated network intrusions have all targeted companies and governmental organizations, it’s the individual consumer's personal information that ultimately is the most valuable to a cybercriminal. "We should be conscious of the fact that we cannot trust companies to protect our data properly and be cautious who we give our information to," Wisniewski said. "Do we really need to provide our full name, postal code, birth date, etc. to get a frequent shopper card at the supermarket?" [How to Disappear Almost Completely … and Protect Yourself from Data Breaches] To keep your identity and data safe, Krehel advises people to prepare a list of institutions to contact in the event your personal data is stolen. It's also important to never divulge non-essential information such as your mother's maiden name, which can be used to steal your identity, and to use a different password for each online account.

Every Business Needs a Security Plan

Too many businesses wait until it's too late to think about their company's physical security and cybersecurity issues. That's not good for business, according to Mike Howard, chief security officer for Microsoft. Howard, an ex-CIA officer who handles all physical security for the company's worldwide operations, says that integrating a security team or plan into your company's day-to-day operations is the key to getting the most value from it. "Security is not something that should be thought of as 'break glass only in times of emergency,'" he told BusinessNewsDaily in an exclusive interview. "It affects a brand's reputation, can result in lawsuits, and requires initial investments up front." If you don't want to spend money on security now, you'll surely pay more later, he said. Howard should know. His security team is ultimately responsible for the safety and security of Microsoft's entire executive team, its 90,000 employees, roughly 90,000 contractors, 700 facilities in more than 100 countries worldwide and all of the visitors to those facilities. He's also responsible, of course, for all of their computers and hardware and the information it they contain. [The Man Who Keeps Microsoft Safe and Secure] Howard said it's understandable that businesses may not spend a lot of time focusing on security. "Businesses rightly so are focused on making a profit and that's going to be their natural concentration," he said. "I understand a company's main emphasis is not on security." It's a mistake, however, to underestimate the importance of security issues at a business of any size, Howard said. "Companies don't take the time to understand the role of security in an organization," he said, referring to everything from employee safety to theft to cybersecurity. "When it comes time to carve out funds for security, there's a benign lack of knowledge or interest because there are higher priorities." Howard has made it one of his top priorities to educate Microsoft's senior management about how important security is. "Businesses are a microcosm of society and there is a tendency to be in denial about having a general security awareness. The mindset is, it's never going to happen to us." He said that companies tend to want to spend money on what's most likely to give them a visible and timely return on investment.

10 Simple Tips to Avoid Identity Theft

An unfamiliar bill. A call from a bank asking about unknown charges. Being turned down for a loan or an apartment because of red flags in your credit check. All these are signs your identity may have been stolen. Forms of identity theft include using stolen payment-card information to make a purchase; taking control of existing accounts with banks and online payments platforms such as PayPal; and opening new accounts with online sites such as eBay and Amazon, mobile carriers or utilities. The No. 1 consumer complaint filed with the Federal Trade Commission for the past 14 years, identity theft is on the rise. More than 13 million people were victims of identity theft in 2013, according to the latest report from Pleasanton, Calif.-based Javelin Strategy & Research. It's also big money for the thieves, with Javelin estimating $18 billion in identity theft-related losses in the United States for 2013. MORE: Best Identity-Theft Protection Software "The situation around credit card and identity theft is getting worse, and shows no signs in the near or intermediate term of getting any better," said Christopher Budd, a threat-communications manager at Tokyo-based anti-virus company Trend Micro. Identity theft can happen to anyone — there's no single group that is more or less susceptible to being victimized.

iOS 7 Glitch Kills Find My iPhone Without Password

There's an adage among iPhone owners that you should never update your phone to the last version of iOS that works on it, usually because a newer operating system can slow down an older device. Unfortunately, a different kind of glitch appears to affect iPhone 4 and 4S models running iOS 7. It may be possible to turn off Find My iPhone without a password by simply hitting two buttons at the same time, a bonus for iPhone thieves. MORE:Mobile Security Guide: Everything You Need to Know American iPhone tweaker Miguel Alvarado posted a video on his YouTube page yesterday (April 2) demonstrating how to do this. Alvarado showed that if the virtual toggle switch to disable Find My iPhone and the button to delete the attached iCloud account are pressed at the same time, and then the phone is switched off when the Apple ID password is asked for, the security settings can be overridden.

Facebook Could Go Anonymous

Facebook may be feeling some backlash for its lack of privacy and anonymity, both of which users are enamored with, as evidenced by the rapid popularity of anonymous social apps such as Secret and Whisper. According to a report from Re/code, Secret and Facebook may be in talks about how they can work together. One rumor points to an offer of $100 million from Facebook to buy Secret outright. Facebook has a well-documented history of purchasing buzzy new companies — such as the $19 billion it spent on WhatsApp and the $2 billion for Oculus Rift — so this rumor may not be outside the realm of possibility. However, Re/code does say that representatives from both Facebook and Secret declined to comment. MORE: Secret vs. Whisper: Which Anonymous Sharing App is Best? Also giving credence to this rumor is the fact that the social-networking giant recently started playing with ways to log into some Facebook-owned apps anonymously, including Instagram. In an interview with Bloomberg, CEO Mark Zuckerberg admitted that private Facebook Group messaging was one idea that came out of recent Facebook Creative Labs hackathons. Both of these ideas would be contrary to the always-on, constantly-updating-the-world, real-names-only philosophy that Facebook has operated under since its inception. We look forward to finding out more about how Facebook may update its privacy settings, and roll out new features, at the Facebook F8 developers conference later this month.

Social Media Security

No matter what you think about Facebook, you have to admit it's a pretty impressive networking tool. Along with other social media websites, Facebook allows people to stay connected with friends and family. However, there's a darker side to this connection as well: Facebook also connects its user to a number of Internet security risks. To celebrate Facebook's tenth anniversary, SecurityCoverage Inc. shared some interesting facts about today's social networking sites and advice on how users can protect their personal information. Within the past five years, social media sites have seen an explosion in their number of users. In 2008, Facebook and Twitter boasted 100 million users and six million users, respectively. Now over one billion people connect over Facebook and Twitter's user base has almost forty times the number it had five years ago. LinkedIn leaped from 33 million to 225 million users, and Instagram from one million to over 150 million users. In fact, in the span of one minute, there are a hundred thousand new tweets and a hundred new LinkedIn accounts made. A Haven For Hackers Unfortunately, just because everyone uses a site doesn't mean your account on it is 100% safe. This past year was one of the worst in data breaches yet with six million Facebook members affected by a bug that sent private information of users to outside sources. Eight million LinkedIn, eHarmony, and Last.fm passwords were stolen and uploaded to a Russian hacker forum, and 250,000 Twitter users' information was hacked. We've all seen the fake tweets by people pretending to be fictional characters, or even imitating celebrities. In just the first months of 2013, 7.2 percent of social media profiles were fake accounts. While hilarious, these phony identities can be shelters for cybercriminals with malicious intentions. One notable scam on Facebook was hackers' attempts to install malware on victims' devices by offering the option of a "dislike" button on the website. Think Before You Click You've heard this a dozen times, but it's still true: once something's online, it doesn't go away. Think before you post pictures or information you don't want everyone to see. Ten percent of respondents in a survey claim that they've regretted posting something, thirty percent include location in their posts, and nearly forty percent of users' profiles are completely or partially public. Take time to look over the privacy and security settings of the social networking sites you use. Sites update their privacy settings every so often, so it's a good idea to keep yourself in the loop to make sure you know what information is available to the public. Over-sharing isn't just annoying for your online friends; it also makes it easy for cybercriminals to steal your identity, access personal data, or even stalk you. Be careful about how much personal information you decide to share on social networking sites. Don't click on suspicious-looking links or advertisements because it could be cybercriminals aiming to compromise your device. More Tips To Keep In Mind Create strong passwords for each of your logins to help prevent your personal information from getting stolen. A password manager is a great tool to use to generate and store hard-to-crack passwords; one of our favorites is Editors' Choice LastPass 3.0. Keep your computer well protected with antivirus software. There are a lot of great options out there; one of them is our Editors' Choice Norton Antivirus (2014). Always back up your data to a remote location just in case your device gets infected or lost. Be smart about how you monitor your personal data; you don't want crooks getting their hands on it.

Security Think Tank: ISF’s top security threats for 2014

The top security threats global businesses will face in 2014 include bring your own device (BYOD) trends in the workplace, data privacy in the cloud, brand reputational damage, privacy and regulation, cyber crime and the continued expansion of ever-present technology. As we move into 2014, attacks will continue to become more innovative and sophisticated. Unfortunately, while organisations are developing new security mechanisms, cyber criminals are cultivating new techniques to circumvent them. Businesses of all sizes must prepare for the unknown so they have the flexibility to withstand unexpected, high-impact security events. The top six threats identified by the Information Security Forum (ISF) are not the only threats that will emerge in 2014. Nor are they mutually exclusive and can combine to create even greater threat profiles. 1. BYOD trends in the workplace As the trend of employees bringing mobile devices into the workplace grows, businesses of all sizes continue to see information security risks being exploited. These risks stem from both internal and external threats, including mismanagement of the device itself, external manipulation of software vulnerabilities and the deployment of poorly tested, unreliable business applications. If the BYOD risks are too high for your organisation today, stay abreast of developments. If the risks are acceptable, ensure your BYOD programme is in place and well structured. Keep in mind that a poorly implemented personal device strategy in the workplace could face accidental disclosures due to loss of boundary between work and personal data and more business information being held in unprotected manner on consumer devices. 2. Data privacy in the cloud While the cost and efficiency benefits of cloud computing services are clear, organisations cannot afford to delay getting to grips with their information security implications. In moving their sensitive data to the cloud, all organisations must know whether the information they are holding about an individual is personally identifiable information (PII) and therefore needs adequate protection. Most governments have already created, or are in the process of developing, regulations that impose conditions on the protection and use of PII, with penalties for businesses that fail to adequately protect it. As a result, organisations need to treat privacy as both a compliance and business risk issue to reduce regulatory sanctions and commercial impacts. 3. Reputational damage Attackers have become more organised, attacks have become more sophisticated, and all threats are more dangerous, and pose more risks, to an organisation's reputation. With the speed and complexity of the threat landscape changing on a daily basis, all too often businesses are being left behind, sometimes in the wake of reputational and financial damage. Organisations need to ensure they are fully prepared and engaged to deal with these ever-emerging challenges. 4. Privacy and regulation Most governments have already created, or are in the process of creating, regulations that impose conditions on the safeguard and use of PII, with penalties for organisations that fail to sufficiently protect it. As a result, organisations need to treat privacy as both a compliance and business risk issue to reduce regulatory sanctions and commercial impacts, such as reputational damage and loss of customers due to privacy breaches. Different countries’ regulations impose different requirements on whether PII can be transferred across borders. Some have no additional requirements; others have detailed requirements. To determine what cross-border transfers will occur with a particular cloud-based system, an organisation needs to work with its cloud provider to determine where the information will be stored and processed. 5. Cyber crime Cyber space is an increasingly attractive hunting ground for criminals, activists and terrorists motivated to make money, get noticed, cause disruption or even bring down corporations and governments through online attacks. Organisations must be prepared for the unpredictable, so they have the resilience to withstand unforeseen, high-impact events. Cyber crime, along with the increase in online causes (hacktivism), the increase in cost of compliance to deal with the uptick in regulatory requirements, coupled with the relentless advances in technology against a backdrop of under-investment in security departments, can all combine to cause the perfect threat. Organisations that identify what the business relies on most will be well placed to quantify the business case to invest in resilience, therefore minimising the impact of the unforeseen. 6. The internet of things Organisations’ dependence on the internet and technology has continued to grow over the years. The rise of objects that connect themselves to the internet is releasing a surge of new opportunities for data gathering, predictive analytics and IT automation. As increased interest in setting security standards for the internet of things (IoT) escalates, it should be up to the companies themselves to continue to build security through communication and interoperability. The security threats of the IoT are broad and potentially devastating, so organisations must ensure that technology for both consumers and companies adheres to high standards of safety and security. You cannot avoid every serious incident, and while many businesses are good at incident management, few have a mature, structured approach for analysing what went wrong. As a result, they are incurring unnecessary costs and accepting inappropriate risks. By adopting a realistic, broad-based, collaborative approach to cyber security and resilience, government departments, regulators, senior business managers and information security professionals will be better able to understand the true nature of cyber threats and respond quickly and appropriately.