Data Managment

  • RDBMS: Store relational data in a relational database.  Popular open source databases are MySQL, Microsoft SQL Server, Oracle Database, IBM DB2, PostgresSQL, and Sybase.
  • Static Data: It would be good to store customer/user level static data on separate file server. This will include images, CSS, Scripts, Themes and other static content.
  • File Data: Customer/user level dynamic data may resides in Content repository with keys in the database. This can include file upload, documents, workflow, rules etc.
  • Data Caching: Much of the application data should reside in memory when the application is running. 2nd level chache stores cached object in temporary directory. Manipulating temporary files are bit slow therefore you would prefer to use Redis or Memchached based 2nd level cache. You can keep latest history in cache.
  • Cookies: Cookies may contain sensitive data such as session identifiers or data that is used as part of the server-side authorization process. To protect this type of data from unauthorized manipulation, you can use cryptography to encrypt the contents of the cookie.
  • Session Data: You can use security on HTTP Session but make sure your will not store sensitive data in session. You can store user information and current activities. Avoid storing large objects in HTTP session object.
  • Sensitive Data: if data is marked as sensitive then you will have to implement proper encryption on that data.
  • Auditing or Audit Trail: Each transactional table should be configured with four common fields so that you can keep track of user activities
    • Created by
    • Created date
    • Updated by
    • Updated date
  • Parameter Manipulation: Manipulating the data sent between the browser and the web application is something that needs to be considered as well. In a badly designed and developed web application, malicious users can modify things like session tokens or values stored in cookies and even HTTP headers. No data sent to the browser can be relied upon to stay the same unless cryptographically protected at the application layer. Cryptographic protection in the transport layer (SSL) in no way protects one from attacks like parameter manipulation in which data is mangled before it hits the wire. Parameter tampering can often be done with:
    • Form Fields
    • Cookies
    • URL Query Strings
    • HTTP Headers

    Mitigation Techniques and planning is described in following URL:

  • Applications Logs: Application logs are text files prefixed with date. You can store all application logs in <SERVER_HOME>/logs folder. You can keep separate file for type of logs.
  • Configuration/Environment Data: Includes application level configuration data which will be used for deployment and configuration. These are mainly xml and property files which resides under bin folder. Here is list of configuration data:
    • Constants: You can use interface/enum for storing application’s constants. You can keep one common constant file and each module will have their own constant file if required. This will resides under source folder.
    • Libraries & Verisons: Libraries or dependencies and versions will be managed by a project management tool i.e maven, gradle, ant and etc.
    • Profile Data: Profiles are mainly used for deployment. You can keep profile related data in parent project’s pom.xml if maven is used. Here is example of profile:


















Posted in Application Development, Data Management | Tagged , , | Leave a comment

Risks In Software Development

  1. Developing the wrong software function or mis-understanding of requirements. This is minor risk in if you are following pure agile methodology where we can find out this type of risk quickly but it can affect original time estimates.
  2. Performance shortfall- Developing multilayer application where some layers may reside on different server location. In this case request can take some time to process.
  3. A delay in one task causes cascading delays in dependent tasks.
  4. Unfamiliar areas of the product take more time than expected to design and implement such as integration with 3rd party softwares, complex form building, combining components.
  5. Components developed separately cannot be integrated easily, requiring redesign and rework Process.
  6. Non-standard / unmaintainable code written by developers may cause loop hole in the solution. We can overcome this by formal technical reviews of the requirements specification, design, test procedures, test cases and code, conducted regularly.
  7. Injections: Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorised data.
  8. Broken Authentication and Session Management: Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit implementation flaws to assume other users’ identities.
  9. Insecure Direct Object References: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorised data.
  10. Security Misconfiguration: Security depends on having a secure configuration defined for the application, framework, web server, application server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults.
  11. Failure to Restrict URL Access: Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks when these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.
  12. Unvalidated Redirects and Forwards: Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorised pages.
  13. Insecure Cryptographic Storage: Many web application do not properly protect sensitive data such as authentication credentials with appropriate encryption or hashing. Attackers may use this weakly protected data to conduct identity theft.
  14. Insufficient Transport Layer Protection: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.
  15. If the necessary functionality cannot be implemented using the selected code or class libraries; developers must switch to new libraries or custom-build the necessary functionality and which can take longer then expected. For instance data migration, form builder, workflow designer, and complex reports.
  16. Development tools do not work as expected; developers need time to create workarounds or to switch to new tools.
  17. Personnel need extra time to learn unfamiliar software tools or environment.
  18. Personnel need extra time to learn unfamiliar hardware environment e.g. Production server environment with memcached, jenkins, wso2 enterprise service bus, identity server and PostgreSQL.
  19. Personnel need extra time to learn unfamiliar programming language e.g. Dynamic Business rules, Workflow Processes.
  20. New development personnel are added late in the project, and additional training and communications overhead reduces existing team members’ effectiveness.

To be continue…

Posted in Risks | Tagged , , , | Leave a comment

Security Encryption

Jasypt ( ) java simplified encryption can be used for encryption. Jasypt by itself does not implement any algorithms, but it lets you use any JCE provider of your choiceIt has good integration support with Spring, spring-security, hibernate, tapestry and maven. Main features are:

  • High-security, standards-based encryption techniques, both for unidirectional and bidirectional encryption. Encrypt passwords, texts, numbers, binaries…

  • Transparent integration with Hibernate.

  • Suitable for integration into Spring-based applications and also transparently integrable with Spring Security.

  • Integrated capabilities for encrypting the configuration of applications (i.e. datasources).

  • Specific features for high-performance encryption in multi-processor/multi-core systems.

  • Open API for use with any JCE provider.

  • …and much more

There is an good article on “How to encrypt passwords

It is useful:

  • Encrypting (digesting) passwords.

  • Encrypting sensitive information.

  • Encrypting data communications.
Posted in Security Desgin | Tagged , | 1 Comment

Security Design

Document is structured as a list of challenges. For each challenge there are specific checklists.

List of challenges:

  1. Risk Assessment
  2. Authentication
  3. Authorisation and Access Control
  4. Session Management
  5. Data Validations
  6. Cross Site Scripting
  7. Command Injection Flaws
  8. Buffer Overflows
  9. Error Handling
  10. Logging
  11. Web Application & Server Configuration

Risk Assessment

An application determined to be of risk to mission critical data, will require a thorough security component during it’s design phase in development and implementation and into maintenance. We will use the following questions as checkpoints to determine the level of risk posed and the requisite security layers to be added

  • Will any data considered sensitive or confidential be transmitted over external communication links?
  • What would motivate someone to break into the application?
  • Will the application have high external visibility, making it an obvious target to attackers?


The most common form of authentication is the user id and password. Authentication policies, processes, and logging must be designed, developed and documented to assure that the application keeps unauthorized users away from accessing the site. It must correctly identify the true owner of a user id and password.

  • To prevent a user id and/or password from being hacked, failed logins should trigger a lock-out after a determined number of attempts. The account lock-out should be maintained for a number of hours to prevent and discourage the attacker from reissuing the attack. The activity should be logged. All authentication attempts should be logged – log in, log outs, failed logins, password change requests. In addition notification or alerts should be sent to an administrator when the account is locked due to failed logins.
  • An attacker should not be able to deduce the user id. “Bill.Johnson” would not be considered a strong user id, while “bijohn” would be less obvious. Likewise, strong password rules should be applied. A strong password has a minimum of seven characters and it uses three of the following: numbers, uppercase letters, lowercase letters, and symbols. It will have a symbol character in the second – sixth position. A strong password will not use repeated or sequenced characters. It will look random. Finally, the password should not be found in any dictionary.
  • When a password is changed, require the existing password to be entered prior to accepting a new password. It is important to verify that the owner of the user id is the person requesting the password change. When passwords are successfully changed the program should forward a message to the email address of the owner of the user id, and the user should be forced to re-authenticate.
  • When a user forgets a password, the password must be changed rather than “recovered.” Passwords should not be stored in a manner that would allow a recovery. On form based password resets, the use of “secret” questions and answers is recommended. Again, the application should force a new authentication following the password reset.
  • Passwords and user ids must be transmitted and stored in a secure manner. Do not send user ids and passwords in a clear text email message. Should this be a necessity, any passwords sent in clear text must be encrypted using Secure Socket Layer (SSL).
  • Best practice recommends encrypting the entire logon transaction with SSL. Form based authentication must use a POST request to assure that the authentication credentials are not cached to browser history. Using SSL on all login pages will accomplish this. Make use of “no cache” tags to further prevent someone from backing up to a login page and resubmitting a logon. Do not allow the application to cache both user id and password. “Remember me” functionality is not recommended, but if used should allow users to automatically sign in only to non-critical portions of the site.
  • SSL can provide authentication, confidentiality, and integrity for data as it is transported to and from web services. It is important to recognise that SSL doesn’t protect the web application. It protects the “transport” of the data as it moves between the web application server and a browser. SSL is a transport layer protocol that operates between the TCP/IP layer and the Application layer where HTTP operates. Being aware of where SSL encryption is implemented will reduce any false sense of security developers may have when using SSL to secure an application.

Authorisation and Access Control

Authentication tells a user “I recognise you as a user.” Authorization says “Now that I know who you are I also know what you are allowed to do; what data you are allowed to see and modify.” Access control determines where a user can connect from; what time they can connect, and the type of encryption required. The goal is to develop a security strategy to protect back -end and front -end data and systems. This can be accomplished through the use of roles, credentials, and sensitivity labels

  • During the design phase, user roles should be defined based on a “least privilege” model. If a user role will not be modifying data, then the role should not be given any opportunity to edit, delete, or add data to the critical database. Document the user roles during development and determine who will hold the responsibility for assigning users to specific roles.
  • Assure that users cannot “browse” past their user role rights. The user should not be able to access an unauthorized page by entering the location into the URL. Similarly, A user should not be able to enter a file path (\\servername\folder\folder) into a URL that would allow a user to access and potentially modify a system file.
  • Assure that users’ activity is not cached when handling sensitive information. If multiple employees share a workstation, clicking the back arrow should not take a user to the URL of the last users’ login or their last pages visited. This may result in elevated rights.
  • Testing of an application prior to moving it into a production environment will include a review of user role documentation and a review of the code implementing access controls. Penetration testing will be necessary to assure that every access control has been tested and prevents unauthorized access.

Session Management


A common vulnerability of web applications is caused by not protecting account credentials and session tokens. There are four types of session id attacks: interception, prediction, brute-force, and fixation. In each attack an unauthorized user can hijack a session and assume the valid user’s identity. Encrypting sessions is effective against interception; randomly assigned session ids protect against prediction; long keyspaces render brute-force attack less successful, and forcing assignment and frequent regeneration of session ids make fixation less problematic.

HTTP is a stateless protocol. It will answer any HTTP request. HTTP does not, by itself, keep conversations in any specific order. It is important to use a state mechanism to separate and maintain an individual user’s activities within a session. A cookie is a common vehicle used to maintain state in HTTP sessions. The cookie allows a user to make numerous HTTP transactions in one conversation. The session id keeps the various requests together in one conversation.

  • Because cookies are transmitted in clear text, the content of the cookie must not contain or be used to obtain sensitive information. State mechanisms were not designed to manage sensitive information. Therefore, state mechanisms should not be used to authenticate users. The user must be made aware of and agree with the use the application will make of cookie sessions. The user must be able to immediately delete the cookie and the state associated with it. Any information stored within the cookie must not be disseminated to third parties without the users’ consent.
  • Session ids should be unique to users, and issued after successful authentication. They should be randomly generated using a respected randomization source. The session id should never contain personal information. Session ids are always assigned, never chosen by end user. The keyspace of the token must as large as possible to combat guessing and other attacks. A 12 – digit keyspace has 1 trillion possible different codewords. As bandwidth increases, the size of the keyspace must increase to keep hackers out.
  • Session ids must be protected throughout their life cycle to prevent hijacking. They should have a time – out set for inactive sessions. Active sessions should also have a set time to expire and regenerate a new session token. This reduces the time window that a hacker would have to break into a session.
  • Session ids should be protected with SSL. Session ids should change routinely and always during major transitions, i.e., when moving to and from an SSL and when authenticating. For highly secure transactions re-authentication and a new session id should be issued prior to processing the requested transaction.
  • On log out, the session id should be over-written.

Data Input Validations


Cross-Site Scripting and Command Injection take advantage of a “violation of trust” between a user accessing a known and trusted site and an attack er. The attacker bypasses security mechanisms by adding malicious code to open parameters in an application. An open parameter could be a URL, QueryString, Header, Cookie, Form Field, or a Hidden Field. It is any parameter that does not assure that the data entered is data that would normally be expected. For example, if the parameter is a date field, and the input “injected” into it is a script file, then the attacker has been successful in finding and using an open parameter. Well written code would discard the script. The importance of knowing and documenting what is known as valid data cannot be stressed enough.

  • The strongest defense against these attacks is Input Validation. If the server validates all data entering the web application against known good criteria, the chances of successful attack are greatly reduced. The burden of security validation must fall on the server, and hence the application developer, rather than the client. Client-side validation is often used as a primary validation to “reduce round trips to the server,” but should not be used as a security defense.
  • The use of a common library of field validations can be used to more efficiently and accurately confirm the integrity of the entry data.
  • Constrain input–decide what is allowed in the field
  • Validate data–type, length, format, and range
  • Reject “known bad” input – do not rely only on this as it assumes the programmer knows everything that could possibly be malicious.
  • Sanitise Input – This can include stripping a null from the end of a user -supplied string; escaping out values so they are treated as literals, and HTML or URL encoding to wrap data and treat it as a literal.
  • Make strict use of canonicalisation. Know what the server is expecting in every field. All data input must be reduced to a pure format, the format that the server and database expects. Input validation assures that all data is appropriate for its meaningful purpose. It may be necessary to establish character sets on the server to establish the canonical form that input must take.
  • As noted in the Authentication section, an SSL connection is established in the transport layer, after the malicious code is introduced. It is important to recognise that SSL does not protect against in valid data. The SSL connection sees a valid conversation between server and user and transports the malicious code.

Cross Site Scripting (XSS)


When a web application creates output from user input without validating the data, the output can include malicious code. An attacker looks for instances in code where there is no validation and inserts the attack at that point. The output that the user receives may well carry malicious code. The user may receive a “click here” message, and trusting the “known site,” abide by the hackers desire. The result is directed at the end user rather than the application’s infrastructure. This could transmit corporate confidential data to an outside site. It can result in program installations or disclosure of end user files.

  • All code must be reviewed for input variables that result in output and have no validation included. All headers, cookies, query strings, form fields, and hidden fields accepting input are validated against acceptable data lists. Every field must have a list of acceptable values.
  • Replacing the following characters will also defeat XSS.















Command Injections Flaws


Command injection flaws allow attackers to relay malicious code through the web application to another system. The malicious code can include whole scripts. SQL injection is the most prevalent. SQL injection attaches specifically to a parameter that passes through to an SQL data base allowing an attacker to modify, erase, copy, or corrupt an entire database. SQL Injections can take the following forms: Authorization (Authentication), Select Statement, Insert, and procedures.

  • Review for SQL injection is time consuming. All parameters must be examined for calls to external sources. Review the code for any instance where input from an HTTP request could be written into any of these external calls.
  • Build filters that verify that only expected data is included. If symbols are required, assure that they are converted to HTML.
  • Prepend and append a quote to all user input.
  • Wherever possible avoid shell commands and system calls. In many cases there are language libraries that perform the same functions without using a system shell interpreter. Where shell commands cannot be avoided, the code must validate the input against a valid input list to ensure that it does not include malicious code. Consider all supplied input as data, reducing, though not eliminating external calls.
  • In the event of data that is not acceptable, there should be a mechanism in place to block and time out the session.

Buffer Overflows


“The buffer overflow attack involves sending large amounts of data that exceed the quantities expected by the application within a given field. Such attacks cause the application to abandon its normal behavior and begin executing commands on behalf of the attacker.” Attackers find buffer overflow vulnerabilities by searching for system calls and functions that do not restrict the length and type of input. This can be done manually or electronically with a code inspection tool. The attacker can also run a brute force attack against the program in the hope of finding vulnerabilities in the code. Once the attacker finds a vulnerability, custom code is inserted that does not crash the system, rather instructs it to execute other commands or programs of the attackers desire.

  • All code that accepts input from users via an HTTP request must be reviewed to ensure that it can identify large input. Once inappropriate data is identified the activity must be logged and the data dropped.
  • All data input fields must have reasonable field lengths and specific data types. Limit the amount of text allowed in free form fields.
  • Routinely check the code of web applications during their development phase to assure that the design is secured as built.

Insecure Use of Cryptography


Apply encryption to any part of the program that affects critical or confidential data. Assure that all elements of encryption are securely stored. Encryption schemas should be developed by a commercial company rather than developed internally. Encryption is fairly easy to add to an application, but it is often not done correctly.

Some common mistakes are:

  • Insecure storage of keys, certificates, and passwords
  • Improper storage of secrets in memory
  • Poor source of randomness
  • Poor choice of algorithm or internally developed algorithms
  • Failure to encrypt critical data
  • Attempt to invent a new encryption algorithm
  • Failure to include support for encryption key changes and maintenance procedures
  • Determine what data is critical or vulnerable and develop encryption schemes to sheild the data from unauthroized users and use. Encryption adds latency to the application, therefore it may be prudent to apply encryption to specific parts of the site, for example, the authentication pages.
  • Review the code to learn how critical data is secured. The review should also identify how keys, passwords, and other secrets are stored, loaded, processed, and cleared from memory.
  • Assure the developer’s choice of randomness and algorithm is of high quality. The programmer should not build the algorithm or the randomness. There are numerous professional sources available for both.

Error Handling


Errors are inevitable. Errors can be caused by user, programs, or perhaps they are errors between two systems. During development and testing an effort is made to identify all potential errors and appropriate error messages are developed for the end user. There will also be errors that are unanticipated. The application must have protocols for these errors as well. Left “un-handled,” the administrator has no idea that an error has occurred. The procedure for handling the unanticipated needs to include what the error was, when it occurred, and where it occurred.

  • During development write a policy for handling errors. Determine which errors should trigger a response to the end user. Carefully write error pages with appropriate information. The error page reported to the end user must be carefully crafted to give the user some information. However, an attacker can learn a tremendous amount of information about a website from default error messages. The messages “file not found” or “access denied” give hackers information about the file system structure and its permissions. Determine which errors should be logged.
  • Log un-handled errors to an event log. Include time and date, user id, error code, if possible the code line. This log should be encrypted as it is critical information.
  • Thoroughly test the application to determine the possible errors. Decide what the programmatic response will be to known errors. Write error pages that reflect enough information to the end user without giving the user information about the code, the file system, or permissions.
  • When an error occurs that causes the program or a part of the program to fail , it is vital that the system will “fail closed,” blocking an  unauthorized user from reaching the operating system or the site. The action that caused the error should be logged and then blocked.



Logging is crucial to an organization’s ability to track unauthorized access and to determine if any access attempt was successful. Logs provide individual accountability. They are vital to reconstruction of events leading to a program failure. Log as much as possible. Logs are often required in any legal proceedings.

  • Begin by synchronizing your servers and syslog server to a time server. Time and date stamps must be accurate.
  • Preserve a baseline of your network to be used as a comparison point in the event of system failure.
  • The following items will make any log entry meaningful:
  • Date and Time
  • Initiating Process
  • Process Owner
  • Description
  • Log all Authentication and Authorisation Events–logging in, logging out, failed logins. These should include date/time, success/failure, resources being authorised  and the user requesting the authorisation  if appropriate an IP address or location of the Authentication Attempt.
  • Log all Administrator activity. All of it.
  • Log the deletion of any data.
  • Log any modification to data characteristics: permissions, location, field type.
  • Log files are critical data. They should be encrypted. If your environment is highly secure consider WORM technology to protect the log files from deletion or modification.
  • Develop a procedure for archiving log files. Consider encrypting this critical data.

Web Application and Server Configuration


Out of the box, servers are laden with vulnerabilities. They must be patched before web services are installed. All default settings should be reviewed; and unnecessary services deleted or disabled.

  • Configure server disks to allow for the separation of the operating system and the web server. This will allow the restriction of directory traversal to inappropriate locations.
  • Verify that assigned file and directory permissions are correctly applied using “least privilege” mode.
  • Disable any services that are not used by the web server or applications.
  • Delete default accounts and their default passwords
  • Rename the default Administrator account or make it inaccessible. Delete all guest accounts.
  • Disable debugging functions.
  • Edit error messages to provide as little information as possible to a hacker.
  • Do not use self-signed SSL certificates, or default certificates. Assure that SSL certificates and encryption settings are properly configured.
  • Scan from the outside network to assure that all unnecessary ports are closed. Run port scans monthly to assure that nothing has been changed.
  • Assign security maintenance to an individual or team to be responsible for: monitoring latest security vulnerabilities; testing and applying the latest patches; updating security configuration guidelines; regular vulnerability scanning; regular status reports to upper management; and documenting the overall security practice or posture.
Posted in Security Desgin | Tagged , , , | Leave a comment

How to setup WSO2 Stratos 1.6.0 Local Instance:

How to setup WSO2 Stratos 1.6.0 Local Instance:


  1. Go through README file located in <<STRATOS_HOME>>/README

  2. will setup mysql database, user accounds and grants. if everything is goes well then you will see “Creating user accounts and grants .. [DONE]” message on your console. You can also verify that all the user accounts exists or not.


Here is list of newly created users (rss_db, hive_user, shopping_cart_db, billing, bps, registry and userstore) :


  1. Now you are ready to execute startup script. Execute start <<list of services>> for instance:  ./ start ‘manager as_mgt’ this will start two servers stratos manager and application server. You can look into log file for status of execution.

    for above command you will have to browse



if everything is ok then you will see WSO2 Carbon started in xx sec


  1. How to access management dashboard:
    Stratos manager:

    Application Server:


if you are lucky then you will reach at

    SAML 2.0 based Single Sign-On

    RealyState is not present in the request.

    This request will not be processed further.


It mean ELB server is not started. You have to start ELB server along with manager. Both manager and ELB server is mandatory. ELB server will run separately. This is not part of Stratos script. ELB server is located in <STRATOS_HOME>/wso2elb-2.0.2


WSO2 team will update README for the same.


  1. Start ELB Server

  2. Browse

  3. Thats it.


Posted in Extra | Tagged , , , | Leave a comment

Scala Notes

 Step By Step

  1. The name Scala stands for “scalable language”.
  2. Scala is pronounced skah-lah.
  3. It runs on the standard Java platform and interoperates seamlessly with all Java libraries.
  4. Scala is a blend of object-oriented and functional programming concepts in a statically typed language. (Static typing can find type errors reliably at compile time. This should increase the reliability of the delivered program. However, programmers disagree over how commonly type errors occur, and thus disagree over the proportion of those bugs that are coded that would be caught by appropriately representing the designed types in code. Static typing advocates believe programs are more reliable when they have been well type-checked, while dynamic typing advocates point to distributed code that has proven reliable and to small bug databases.)
  5. Scala comes with a standard library. Sometimes you might not agree with “one size fits all” philosophy, because you need to control the properties of the some libraries such as maps you use in your program in a more fine-grained way. Scala gives you this fine-grained control if you need it. For more information, you can also consult the library’s Scaladoc documentation, which is available in the distribution and online at
  6. Scala is much more like a bazaar than a cathedral, in the sense that it is designed to be extended and adapted by the people programming in it. (Eric Raymond introduced cathedral and bazaar as two metaphors of software development. The cathedral is a near-prefect building that takes a long time to build. Once built, it stays unchanged for a long time. The bazaar, by contrast, is adapted and extended each day by the people working in it. The bazaar is metaphor for open source software development.)


  1. Programming in Scala, Second Edition
  2. Static and Dynamic types
  3. Cathedral and Bazaar :

Posted in Scala | Tagged , , , , | 2 Comments

Root User ( Super User ) in Ubuntu

Warning: Enabling root is not recommended. If possible, you should always try to perform all administrative tasks using sudo.

#01: unable to login

$ su -
su: Authentication failure

Enable super user account password on Ubuntu

$ sudo passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Posted in ubuntu | Tagged , , , , | Leave a comment