Dropdown Tree – Dynamic Dropdown Menu with jQuery and Bootstrap

Dropdown Tree is a dynamic dropdown menu, based on Bootstrap and jQuery with click handlers, data handlers. You can select single or multi items, and can bind remote data with ajax request.

by via jQuery-Plugins.net RSS Feed

Your Apple iCloud Data Is Now Stored On Google Cloud Platform — Surprised?

Apple has updated its publicly available iOS security documentation to disclose that personal data associated with the company’s iCloud service is stored in cloud servers operated by Google—specifically, the Google Cloud service. Apple didn’t specify exactly what iCloud data is stored on Google’s...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Irfan Ahmad via Digital Information World

YouTube rolls out new chat replay, automatic captions and more for live streaming videos

After taking away a demographic data from creators last week, YouTube is giving something back and expanding its list of features for creators who film live stream videos. According to an announcement on the YouTube blog, live streaming will now include chat replay, automatic English captions,...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Irfan Ahmad via Digital Information World

Galaxy S9: Samsung’s 9 best features [video]

Samsung on Sunday finally announced its hotly anticipated flagship smartphones, the Galaxy S9 and Galaxy S9+, and like most years, they have several new features alongside welcome improvements. What are the best features of the Galaxy S9? We’ve picked out the top nine reasons you might want to buy...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Web Desk via Digital Information World

Storing Data Securely on Android

An app's credibility today highly depends on how the user's private data is managed. The Android stack has many powerful APIs surrounding credential and key storage, with specific features only available in certain versions. This short series will start off with a simple approach to get up and running by looking at the storage system and how to encrypt and store sensitive data via a user-supplied passcode. In the second tutorial, we will look at more complex ways of protecting keys and credentials.

The Basics

The first question to think about is how much data you actually need to acquire. A good approach is to avoid storing private data if you don't really have to.

For data that you must store, the Android architecture is ready to help. Since 6.0 Marshmellow, full-disk encryption is enabled by default, for devices with the capability. Files and SharedPreferences that are saved by the app are automatically set with the MODE_PRIVATE constant. This means the data can be accessed only by your own app. 

It's a good idea to stick to this default. You can set it explicitly when saving a shared preference.

SharedPreferences.Editor editor = getSharedPreferences("preferenceName", MODE_PRIVATE).edit();
editor.putString("key", "value");
editor.commit();

Or when saving a file.

FileOutputStream fos = openFileOutput(filenameString, Context.MODE_PRIVATE);
fos.write(data);
fos.close();

Avoid storing data on external storage, as the data is then visible by other apps and users. In fact, to prevent make it harder for people to copy your app binary and data, you can disallow users from being able to install the app on external storage. Adding android:installLocation with a value of internalOnly to the manifest file will accomplish that.

You can also prevent the app and its data from being backed up. This also prevents downloading the contents of an app's private data directory using adb backup. To do so, set the android:allowBackup attribute to false in the manifest file. By default, this attribute is set to true.

These are best practices, but they won't work for a compromised or rooted device, and disk encryption is only useful when the device is secured with a lock screen. This is where having an app-side password that protects its data with encryption is beneficial.

Securing User Data With a Password

Conceal is a great choice for an encryption library because it gets you up and running very quickly without having to worry about the underlying details. However, an exploit targeted for a popular framework will simultaneously affect all of the apps that rely on it. 

It's also important to be knowledgeable about how encryption systems work in order to be able to tell if you're using a particular framework securely. So, for this post we are going to get our hands dirty by looking at the cryptography provider directly. 

AES and Password-Based Key Derivation

We will use the recommended AES standard, which encrypts data given a key. The same key used to encrypt the data is used to decrypt the data, which is called symmetric encryption. There are different key sizes, and AES256 (256 bits) is the preferred length for use with sensitive data.

While the user experience of your app should force a user to use a strong passcode, there is a chance that the same passcode will also be chosen by another user. Putting the security of our encrypted data in the hands of the user is not safe. Our data needs to be secured instead with a key that is random and large enough (ie. that has enough entropy) to be considered strong. This is why it's never recommended to use a password directly to encrypt data—that is where a function called Password-Based Key Derivation Function (PBKDF2) comes into play. 

PDKDF2 derives a key from a password by hashing it many times over with a salt. This is called key stretching. The salt is just a random sequence of data and makes the derived key unique even if the same password was used by someone else. Lets start by generating that salt. 

SecureRandom random = new SecureRandom();
byte salt[] = new byte[256];
random.nextBytes(salt);

The SecureRandom class guarantees that the generated output will be hard to predict—it is a "cryptographically strong random number generator". We can now put the salt and password into a password-based encryption object: PBEKeySpec. The object's constructor also takes an iteration count form making the key stronger. This is because increasing the number of iterations expands the time it would take to operate on a set of keys during a brute force attack. The PBEKeySpec then gets passed into the SecretKeyFactory, which finally generates the key as a byte[] array. We will wrap that raw byte[] array into a SecretKeySpec object.

char[] passwordChar = passwordString.toCharArray(); //Turn password into char[] array
PBEKeySpec pbKeySpec = new PBEKeySpec(passwordChar, salt, 1324, 256); //1324 iterations
SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
byte[] keyBytes = secretKeyFactory.generateSecret(pbKeySpec).getEncoded();
SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

Note that the password is passed as a char[] array and the PBEKeySpec class stores it as a char[] array as well. char[] arrays are usually used for encryption functions because while the String class is immutable, a char[] array containing sensitive information can be overwritten—thus removing the sensitive data entirely from the device's phyc RAM.

Initialization Vectors

We are now ready to encrypt the data, but we have one more thing to do. There are different modes of encryption with AES, but we'll be using the recommended one: cipher block chaining (CBC). This operates on our data one block at a time. The great thing about this mode is that each next unencrypted block of data is XOR’d with the previous encrypted block to make the encryption stronger. However, that means the first block is never as unique as all the others! 

If a message to be encrypted were to start off the same as another message to be encrypted, the beginning encrypted output would be the same, and that would give an attacker a clue to figuring out what the message might be. The solution is to use an initialization vector (IV). 

An IV is just a block of random bytes that will be XOR’d with the first block of user data. Since each block depends on all blocks processed up until that point, the entire message will be encrypted uniquely—identical messages encrypted with the same key will not produce identical results. Lets create an IV now.

SecureRandom ivRandom = new SecureRandom(); //not caching previous seeded instance of SecureRandom
byte[] iv = new byte[16];
ivRandom.nextBytes(iv);
IvParameterSpec ivSpec = new IvParameterSpec(iv);

A note about SecureRandom. On versions 4.3 and under, the Java Cryptography Architecture had a vulnerability due to improper initialization of the underlying pseudorandom number generator (PRNG). If you are targeting versions 4.3 and under, a fix is available.

Encrypting the Data

Armed with an IvParameterSpec, we can now do the actual encryption.

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
byte[] encrypted = cipher.doFinal(plainTextBytes);

Here we pass in the string "AES/CBC/PKCS7Padding". This specifies AES encryption with cypher block chaining. The last part of this string refers to PKCS7, which is an established standard for padding data that doesn't fit perfectly into the block size. (Blocks are 128 bits, and padding is done before encryption.)

To complete our example, we will put this code in an encrypt method that will package the result into a HashMap containing the encrypted data, along with the salt and initialization vector necessary for decryption.

private HashMap<String, byte[]> encryptBytes(byte[] plainTextBytes, String passwordString)
{
    HashMap<String, byte[]> map = new HashMap<String, byte[]>();
    
    try
    {
        //Random salt for next step
        SecureRandom random = new SecureRandom();
        byte salt[] = new byte[256];
        random.nextBytes(salt);

        //PBKDF2 - derive the key from the password, don't use passwords directly
        char[] passwordChar = passwordString.toCharArray(); //Turn password into char[] array
        PBEKeySpec pbKeySpec = new PBEKeySpec(passwordChar, salt, 1324, 256); //1324 iterations
        SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        byte[] keyBytes = secretKeyFactory.generateSecret(pbKeySpec).getEncoded();
        SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

        //Create initialization vector for AES
        SecureRandom ivRandom = new SecureRandom(); //not caching previous seeded instance of SecureRandom
        byte[] iv = new byte[16];
        ivRandom.nextBytes(iv);
        IvParameterSpec ivSpec = new IvParameterSpec(iv);

        //Encrypt
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
        cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
        byte[] encrypted = cipher.doFinal(plainTextBytes);

        map.put("salt", salt);
        map.put("iv", iv);
        map.put("encrypted", encrypted);
    }
    catch(Exception e)
    {
        Log.e("MYAPP", "encryption exception", e);
    }

    return map;
}

The Decryption Method

You only need to store the IV and salt with your data. While salts and IVs are considered public, make sure they are not sequentially incremented or reused. To decrypt the data, all we need to do is change the mode in the Cipher constructor from ENCRYPT_MODE to DECRYPT_MODE. The decrypt method will take a HashMap that contains the same required information (encrypted data, salt and IV) and return a decrypted byte[] array, given the correct password. The decrypt method will regenerate the encryption key from the password. The key should never be stored!

private byte[] decryptData(HashMap<String, byte[]> map, String passwordString)
{
    byte[] decrypted = null;
    try
    {
        byte salt[] = map.get("salt");
        byte iv[] = map.get("iv");
        byte encrypted[] = map.get("encrypted");

        //regenerate key from password
        char[] passwordChar = passwordString.toCharArray();
        PBEKeySpec pbKeySpec = new PBEKeySpec(passwordChar, salt, 1324, 256);
        SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        byte[] keyBytes = secretKeyFactory.generateSecret(pbKeySpec).getEncoded();
        SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

        //Decrypt
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
        IvParameterSpec ivSpec = new IvParameterSpec(iv);
        cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec);
        decrypted = cipher.doFinal(encrypted);
    }
    catch(Exception e)
    {
        Log.e("MYAPP", "decryption exception", e);
    }

    return decrypted;
}

Testing the Encryption and Decryption

To keep the example simple, we are omitting error checking that would make sure the HashMap contains the required key, value pairs. We can now test our methods to ensure that the data is decrypted correctly after encryption.

//Encryption test
String string = "My sensitive string that I want to encrypt";
byte[] bytes = string.getBytes();
HashMap<String, byte[]> map = encryptBytes(bytes, "UserSuppliedPassword");

//Decryption test
byte[] decrypted = decryptData(map, "UserSuppliedPassword");
if (decrypted != null)
{
    String decryptedString = new String(decrypted);
    Log.e("MYAPP", "Decrypted String is : " + decryptedString);
}

The methods use a byte[] array so that you can encrypt arbitrary data instead of only String objects. 

Saving Encrypted Data

Now that we have an encrypted byte[] array, we can save it to storage.

FileOutputStream fos = openFileOutput("test.dat", Context.MODE_PRIVATE);
fos.write(encrypted);
fos.close();

If you didn't want to save the IV and salt separately, HashMap is serializable with the ObjectInputStream and ObjectOutputStream classes.

FileOutputStream fos = openFileOutput("map.dat", Context.MODE_PRIVATE);
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(map);
oos.close();

Saving Secure Data to SharedPreferences

You can also save secure data to your app's SharedPreferences.

SharedPreferences.Editor editor = getSharedPreferences("prefs", Context.MODE_PRIVATE).edit();
String keyBase64String = Base64.encodeToString(encryptedKey, Base64.NO_WRAP);
String valueBase64String = Base64.encodeToString(encryptedValue, Base64.NO_WRAP);
editor.putString(keyBase64String, valueBase64String);
editor.commit();

Since the SharedPreferences is a XML system that accepts only specific primitives and objects as values, we need to convert our data into a compatible format such as a String object. Base64 allows us to convert the raw data into a String representation that contains only the characters allowed by the XML format. Encrypt both the key and the value so an attacker can't figure out what a value might be for. In the example above, encryptedKey and encryptedValue are both encrypted byte[] arrays returned from our encryptBytes() method. The IV and salt can be saved into the preferences file or as a separate file. To get back the encrypted bytes from the SharedPreferences, we can apply a Base64 decode on the stored String.

SharedPreferences preferences = getSharedPreferences("prefs", Context.MODE_PRIVATE);
String base64EncryptedString = preferences.getString(keyBase64String, "default");
byte[] encryptedBytes = Base64.decode(base64EncryptedString, Base64.NO_WRAP);

Wiping Insecure Data From Old Versions

Now that the stored data is secure, it may be the case that you have a previous version of the app that had the data stored insecurely. On an upgrade, the data could be wiped and re-encrypted. The following code wipes over a file using random data. 

In theory, you can just delete your shared preferences by removing the /data/data/com.your.package.name/shared_prefs/your_prefs_name.xml and your_prefs_name.bak files, and clearing the in-memory preferences with the following code:

getSharedPreferences("prefs", Context.MODE_PRIVATE).edit().clear().commit();

However, instead of attempting to wipe the old data and hope that it works, it's better to encrypt it in the first place! This is especially true in general for solid state drives that often spread out data-writes to different regions to prevent wear. That means that even if you overwrite a file in the filesystem, the physical solid-state memory might preserve your data in its original location on disk.

public static void secureWipeFile(File file) throws IOException
{
    if (file != null && file.exists())
    {
        final long length = file.length();
        final SecureRandom random = new SecureRandom();
        final RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rws");
        randomAccessFile.seek(0);
        randomAccessFile.getFilePointer();
        byte[] data = new byte[64];
        int position = 0;
        while (position < length)
        {
            random.nextBytes(data);
            randomAccessFile.write(data);
            position += data.length;
        }
        randomAccessFile.close();
        file.delete();
    }
}

Conclusion

That wraps up our tutorial on storing encrypted data. In this post, you learned how to securely encrypt and decrypt sensitive data with a user-supplied password. It's easy to do when you know how, but it's important to follow all the best practices to ensure your users' data is truly secure.

In the next post, we will take a look at how to leverage the KeyStore and other credential-related APIs to store items safely. In the meantime, check out some of our other great articles on Android app development.

• 
  Android SDK
  Showing Material Design Dialogs in an Android App
  Chike Mgbemena
• 
  Android SDK
  Sending Data With Retrofit 2 HTTP Client for Android
  Chike Mgbemena
• 
  Android SDK
  How to Create an Android Chat App Using Firebase
  Ashraff Hathibelagal

by Collin Stuart via Envato Tuts+ Code

Scissors & Clippers

Unique content browsing in this centrally-divided One Pager for Scissors & Clippers – a pop up barbershop and portrait series exhibition celebrating women and gender nonconforming individuals who cut and rock short hair.

Full Review | Direct Link

by Rob Hope @robhope via One Page Love

The 5 Most Popular Front-end Frameworks Compared

There’s a deluge of CSS front-end frameworks available nowadays. But the number of really good ones can be narrowed down to just a few. In this article, I’ll compare what I think are the five best front-end frameworks available today.

Each framework has its own strengths and weaknesses, and specific areas of application, allowing you to choose based on the needs of a specific project. For example, if your project is simple, there’s no need to use a complex framework. Also, many of the options are modular, allowing you to use only the components you need, or even mix components from different front-end frameworks.

The front-end frameworks I’m going to explore are presented based on their GitHub popularity, beginning with the most popular, which is, of course, Bootstrap.

Note that some of the information below will go out of date in the coming weeks and months – such as GitHub stars and version numbers – so be aware of this if you’re reading this article long after the publication date. Also note that the framework sizes are the minified sizes of the necessary CSS and JavaScript files.

1. Bootstrap

Bootstrap is the undisputed leader among the available front-end frameworks today. Given its huge popularity, which is still growing every day, you can be sure that this wonderful toolkit won’t fail you, or leave you alone on your way to building successful websites.

• Creators: Mark Otto and Jacob Thornton.
• Released: 2011
• Current version: 4.0
• Popularity: 121,374 stars on GitHub
• Description: “Sleek, intuitive, and powerful front-end framework for faster and easier web development.”
• Core concepts/principles: RWD and mobile first.
• Framework size: 578 KB (precompiled zip folder)
• Preprocessor: Sass
• Responsive: Yes
• Modular: Yes
• Starting templates/layouts: Yes
• Icon set: Not included
• Extras/Add-ons: None bundled, but many third-party plugins are available.
• Unique components: Jumbotron, Card
• Documentation: Excellent
• Customization: Option for separate files for Grid system and Reboot, easy customization with Sass; no online customizer
• Browser support: Latest releases of Firefox, Chrome, Safari, IE810-11-Microsoft Edge.
• License: MIT

Notes on Bootstrap

The main strength of Bootstrap is its huge popularity. Technically, it’s not necessarily better than the others in the list, but it offers many more resources (articles and tutorials, third-party plugins and extensions, theme builders, and so on) than the other four front-end frameworks combined. In short, Bootstrap is everywhere. And this is the main reason people continue to choose it.

Note: By saying “unique components”, I mean that they’re unique compared only to the front-end frameworks mentioned in this list.

2. Foundation by ZURB

Foundation is the second big player in this front-end framework comparison. With a solid company like ZURB backing it, this framework has a truly strong … well … foundation. After all, Foundation is used on many big websites including Facebook, Mozilla, Ebay, Yahoo! and National Geographic, to name a few.

• Creators: ZURB
• Released: 2011
• Current version:6
• Popularity: 26,956 stars on GitHub
• Description: “The most advanced responsive front-end framework in the world”
• Core concepts/principles: RWD, mobile first, semantic
• Framework size: 197.5 KB
• Preprocessors: Sass
• Responsive: Yes
• Modular: Yes
• Starting templates/layouts: Yes
• Icon set: Foundation Icon Fonts
• Extras/Add-ons: Yes
• Unique components: Icon Bar, Clearing Lightbox, Flex Video, Keystrokes, Joyride, Pricing Tables
• Documentation: Good, with many additional resources available.
• Customization: Basic GUI customizer
• Browser support: Chrome, Firefox, Safari, IE9+; iOS, Android, Windows Phone 7+
• License: MIT

Notes on Foundation

Foundation is a truly professional front-end framework with business support, training, and consulting offered. It also provides many resources to help you learn and use the framework faster and easier.

3. Semantic UI

Semantic UI is an ongoing effort to make building websites much more semantic. It utilizes natural language principles, thus making the code much more readable and understandable.

• Creator: Jack Lukic
• Released: 2013
• Current version: 2.2
• Popularity: 39,364 stars on GitHub
• Description: “A UI component framework based around useful principles from natural language”
• Core concepts/principles: Semantic, tag ambivalence, responsive
• Framework size: 806 KB
• Preprocessors: Less
• Responsive: Yes
• Modular: Yes
• Starting templates/layouts: Yes, some basic starter templates are offered
• Icon set: Font Awesome
• Extras/Add-ons: No
• Unique components: Divider, Flag, Rail, Reveal, Step, Advertisement, Card, Feed, Item, Statistic, Dimmer, Rating, Shape
• Documentation: Very good, offering very well-organized documentation, plus a separate website that offers guides for getting started, customizing and creating themes
• Customization: No GUI customizer, only manual customization
• Browser support: Firefox, Chrome, Safari, IE10+ (IE9 with browser prefix only), Android 4, Blackberry 10
• License: MIT

Notes on Semantic UI

Semantic is the most innovative and full-featured front-end framework among those discussed here. The overall structure of the framework and the naming conventions, in terms of clear logic and semantics of its classes, also surpasses the others.

Continue reading %The 5 Most Popular Front-end Frameworks Compared%

by Ivaylo Gerchev via SitePoint