Types of encryption in PHP

Most of us when we create an authentication system or other system that store user passwords use the famous function md5 to encrypt information, which already in 2004 was violated so it lost confidence in the developer community

Therefore many have changed our encryption method one compound other than sha1, md5 and salt. Whereupon we left some dictionaries that are anywhere outside.

Lets see some of examples sha1 encryption, salt and md5

MD5

MD5 is represented by a 32-digit hexadecimal, minimal change within the word will give us how a different encryption result.

SHA1

It is represented by a string of 40 hexadecimal digits, is more secure than MD5 but under brute force is no longer effective.

SALT

It is a hash created by the programmer who adds an explicit reference to the formation of the password string, which thus ceases to belong to common dictionaries, it is the most advisable to encrypt passwords  because only the creator of system is able to know how the phrase is made.

I hope it will be helpful when you have to create a system user or to understand how the types of encryption function.

Continuous Deployment

Continuous Deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.

Continuous deployment is controversial. Most people, when they hear about continuous deployment, think I'm advocating low-quality code. On the contrary, I believe that continuous deployment requires tremendous discipline and can greatly enhance software quality, by applying set of standards to every change to prevent regressions.

To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.

Benefits

• Earlier return on investment for each feature after it is developed, which reduces the need for large capital investments

• Earlier feedback from users on each new feature as it is released to production, which affords techniques such as parallel (or A/B) testing to determine which of two possible implementation is preferred by users

Pitfalls

• To the extent that continuous deployment is viewed as a strategy for quality, it's easy (in particular for developers enamored with the novelty and technical aspects of it) to pick the wrong target, and optimize for "maximum frequency of deployments" - that will not, by itself, result in increased quality.

Password Storage Mistakes

Passwords are suppose to be a secure way for authenticating users of a system. 
Every developer must provide a secure and reliable way for storing passwords. There are quiet a number of ways to go about it.

Storing passwords using reversible encryption means that my password may be decrypted. Someone who has access to the application's system and key, may also readily access my password and the thousands of users at this site. One compromise of the key and ALL passwords are toast.




Hashing

So passwords are not to be stored in plain text, they are not to be stored in encrypted form. Well, password can be hashed, Lets review this.

Hashing, which results in a message digest, is a one-way operation. When a hash table is calculated the input is provided and the result is a fixed length output. The SHA-512 algorithm has a 64 bit output, The SHA-256 has a fixed 32 bit output and bcrypt algorithm has a fixed 60 byte output. For each of these algorithms there is an infinite number of potential inputs, but a finite number of potential outputs, this is called collision. Good cryptographic algorithms make it difficult to find collisions.

So by hashing a password, we've solved the password storage problem. But the problem isn't solved yet. People do crack passwords. Unfortunately, while hashing is irreversible, passwords that have been hashed can still be cracked. A number of cracking methods can be used, including brute force, rainbow tables or password dictionaries. During a password attack, looking up hash value in rainbow table is much faster than hashing and comparing each value in the password dictionary.

Salting

Sometimes you need a little something special to make storing passwords better. Lets say I have a password "abcde". This would easily be cracked, any rainbow table or dictionary attack could be used to find this password. but suppose the developers before they hash the password, append a large random string (aka salt). So rather than calculating the hash for abcde, they instead store the large random character string (salt) along with the password. When the application developers decided to use salts when hashing, they effectively made my trivially simple password much more complex and made it very unlikely that someone could crack the password on a pre-computed dictionary attack or through the use of a pre-computed rainbow table. Rather, with a sufficiently large random salt, an attacker must create a separate dictionary or rainbow table for each user's password they are trying to crack. This is extraordinarily expensive and that is why strong salts effectively break dictionary attacks and rainbow tables.

Well there are several other ways for storing passwords. Feel free to explore them.

Mobile app and Web app... Which is to be preferred?

In the pre-app era the word "application" had been applied to websites that provided advanced user interactions and capabilities previously available through native software. Examples of search apps are Webmail, Google maps, Google Docs, news sites etc...

In the era where the demand of mobile telephony is on the ascendancy, be it a smart phone or a tablet, there has been an increase in the number of mobile applications on the market in every platform and domain. But the power of the web cannot not be underestimated. 

Mobile device sales rose in 2011, with smartphones showing the strongest growth. Nokia remains the number one handset manufacturer, but Samsung is the leading smartphone hardware vendor with android being the top smartphone operating system. Android now powers more than 250 million devices, with a user base increasing by 700,000 subscribers per day. This goes to show the increase in mobile users globally.

Each of these types of apps has their own pros and cons. Here is a summary...

Working offline. A mobile app is best if your app must work when there is no internet connectivity. Though HTML 5 supports caching, it is still limited comparatively.

Speed. Native apps win the speed race. The speed of web apps depends on a persons internet connectivity.

Maintenance. Maintaining a native mobile app can be complicated both for users and developers (dealing with multiple versions of the same information on different platforms). New versions of mobile apps will have to be packaged and placed in the app store. On the hand, maintaining a web app is simple as maintaining a web page and changes can be done frequently as needed.

Platform independence. While different browsers may support different versions of HTML 5, if platform independence is important, you definitely have a better chance of achieving it with web apps than with mobile apps.

Installation. Installing web app is a hassle for users: They need to be really motivated to justify the effort. “Installing” a web app involves creating a bookmark on the home screen; this process, while arguably simpler than downloading a new app from an app store, is less familiar to users, as people don’t use bookmarks that much on mobile.

In a nutshell mobile apps and web apps are all ways to cater for the mobile user. There is no unique best solution, each has its strength and weakness. The choice remains with what you want to achieve, target group and the developers preference.

Why NoSQL?

A NoSQL database provides a way for storage and retrieval that uses loosely consistency models than traditional relational database.
NoSQL is a whole new way of thinking about databases. Relational database may not be the best solution to all scenarios. NoSQL does not observe the traditional relational database structure. It is not built on tables and does not need SQL to manipulate data.

Interactive applications have changed greatly over the last 15 years and, so have data management needs. Currently three interrelated trends Big Data, Big Users, and Cloud Computing are driving the idea of NoSQL.
Currently new applications are being hosted in the cloud and are available over the internet where they must support global users everyday. Over 2.5 billion people are connected to the internet worldwide and the amount of time each spends online is steadily growing. Supporting large number of users simultaneously is important but tracking the usage of applications is difficult to determine so its necessary to support rapid growing numbers of concurrent users. Maintaining the performance users demand is nearly impossible and developers are moving away from relational technologies to a more scalable database technology  which NoSQL provides.

Third parties such as Twitter, Facebook and others have made data capture and retrieval a lot easier than it used to be. Personal user information, machine logging data and an array of ever-expanding data are being captured. The use of data is increasingly changing and the nature of its usage. Applications that do not find ways to balance it quickly fall behind. NoSQL provides  a data model that maps better to the application’s organization of data and simplifies the interaction between the application and the database, resulting in less code to write, debug, and maintain.

There are some great NoSQL databases such as

MongoDB,

RethinkDB,

 

Elasticsearch,

 

Couchbase Server

 amongst others which can be of great usage.

NoSQL databases meets new challenges for three main reasons:

1. Better application development productivity through more flexible data model
2. Great ability to scale dynamically to support more users and data
3. Improved performance for highly responsive applications and to allow more complex processing of data.

Why All These Scripting Languages

Over the last fifteen years, there has been a fundamental change in the way people write computer programs. The transition from system programming languages like C or C++ to scripting languages like Perl or PHP has risen up because of the use of the internet as a communication tool.

The main characteristics of a scripting language is its ease of usage and they are usually interpreted from source code unlike system programming languages.
Scripting programming languages such as Python, Rexx, Unix shells, Perl and Tcl represent a very unique style of programming than system programming languages. These languages are intended for writing programs from scratch and fixing components together.

There are a lot of scripting languages in the system and here are some of the popular ones;

Perl (Practical Extraction and Report Language). This is a popular string processing language for writing small scripts for system administrators and web site maintainers. Much web development is now done using Perl.
JavaScript, perhaps the most publicised and well-known scripting language was initially developed by Netscape as LiveScript to allow more functionality and enhancement to web page authoring that raw HTML could not accommodate.
VBScript, a cut-down version of Visual Basic, used to enhance the features of web pages in Internet Explorer.
Python is a widely used general purpose, high-level programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than would be possible in languages such as C. The language provides constructs intended to enable clear programs on both a small and large scale.
PHP is a server-side scripting language designed for web development but also used as a general purpose programming language. PHP code is interpreted by a web server with a PHP processor module which generates the resulting web page: PHP commands can be embedded directly into an HTML source document rather than calling an external file to process data. It has also evolved to include a command line interface capability and can be used in standalone graphical application.

New languages often learn from existing languages and add, remove and combine features in a new way. There is a few different paradigms like object oriented and functional and many modern languages try to mix features from them both.

For the same reason there are hammers, screwdrivers, handsaws, bandsaws, jackhammers, crowbars, and a host of other tools: not every language is perfect for every task. Some languages are targeted at specific problem domains

Also, for the same reason that shirts come in different colors: some people just like the "style" of one language over another.

And, of course, a lot of programmers find it fun to invent a new language, just to see what happens, or perhaps because they have some knowledge about languages and want to scratch an itch, or try out some ideas.

The Open Source Ideology

In the development of software, open source signifies that a product includes permission to use its source code, design documents, or contents.
There has been conflicting definitions and differences between the free software movement and the open source movement.

The term “open source” software is used by some people to mean more or less the same category as free software. It is not exactly the same class of software: they accept some licenses that we consider too restrictive, and there are free software licenses they have not accepted. However, the differences in extension of the category are small: nearly all free software is open source, and nearly all open source software is free. 
-- Free Software foundation  http://www.gnu.org/philosophy/categories.html

Though the market for open source software is on the high, there is still a school of thought against it.
There are many reasons projects should go open source, a few are:

By uploading your codes to sites like GitHub, it makes your code available to people with similar ideas to yours. People can help improve your project and probably make suggestions to to guide you.

Writing a complete software is an arduous task. Lets face it, our ideas can't always be the best. By allowing others access to our software, we can get have the knowledge and expertise of our contributors. Going open source leads your software to be of a better quality.

Going open source doesn't make your project free, you can keep some parts of your code as private as you want it. People have the notion that making their codes available would give their competitors the upper hand. But consider that you have a lot of contributors to your project which will far outweigh what your competitor can get.

I hope these few tips has changed your perception about going open source. You can go around and explore some open source software or start making your project open.