bj-habibie-1000-ilmuwan.jpg

Bantu Jokowi Benahi Negara, BJ Habibie Ingin Himpun 1.000 Ilmuwan

Mantan Presiden ke-3 RI BJ Habibie meminta pengurus Akademi Ilmu Pengetahuan Indonesia (AIPI) meningkatkan jumlah anggota. Ia menargetkan pada puncak perayaan ulang tahun ke-25 AIPI pada 13 Oktober 2015, 1.000 ilmuwan bersedia bergabung membantu bangsa memberi pencerahan dalam bidang pengetahuan.

“Saya minta Anda memperbesar jumlah anggota. Rakyat Indonesia ratusan juta orang, masa anggota kita hanya 100? Saya minta 1.000 anggota Oktober nanti. Saya targetkan itu,” ujar Habibie di kediamannya, Jalan Patra Kuningan XIII, Jakarta Selatan, Minggu (24/5/2015).

Sebagai salah satu pemrakarsa AIPI, Habibie mengatakan, 1.000 ilmuwan ini harus menjadi guidance atau penuntun bangsa, termasuk pemimpinnya. Para ilmuwan itu diharapkan mampu mencerdaskan bangsa di berbagai sektor.

“Saya minta diberikan 1.000 ilmuwan. Itu bisa ada di bagian sosial politik, kedokteran, riset, teknologi, dan lain-lain. It’s okay, itu nanti tergantung pembangunan negeri ini, karena dia (Presiden Jokowi) butuh guidance,” sambung dia.

Meski organisasi AIPI ini belum memiliki nama besar di luar negeri, tetapi ilmuwan yang menciptakan pesawat CN 250 ini, meminta lembaga tersebut menjadi yang terbaik di negeri sendiri.

“Kita harus berada di ujung tombak. Bersyukur, kita sudah 25 tahun exercise, kalau di luar kita belum baik, tapi di bumi negeri sendiri kita harus paling baik,” pungkas Habibie. (Rmn/Yus)

Like this article? Please share this article with others:
google-cl-CLI-command-line-tool-cloud-API.png

Google CL: Command-line (CLI) Tool for Google Cloud Service APIs

 

GoogleCL brings Google services to the command line (CLI). Great for DevOps job or for those loving the shell / console.

GoogleCL currently support the following Google services:

$ google blogger post --title "foo" "command line posting"

  • Blogger

$ google calendar add "Lunch with Jim at noon tomorrow"

  • Calendar

$ google contacts list Bob name,email > the_bobs.csv

  • Contacts

$ google docs edit "Shopping list"

  • Docs

$ google finance create-txn "Savings Portfolio" NASDAQ:GOOG Buy

  • Finance

$ google picasa create "Cat Photos" ~/photos/cats/*.jpg

  • Picasa

$ google youtube post --category Education killer_robots.avi

  • Youtube

Check out the Manual and ExampleScripts for many more examples of what you can do, or the Install page for simple install instructions. 

Like this article? Please share this article with others:

Ubuntu Gutsy 7.10 di Axioo Neon TVR856C/TVR016C

TVR 856C 3

Baru-baru ini kami “mendapat” laptop alias notebook dengan model Axioo Neon TVR 856C. Tugas yang kami terima adalah, “si bos” mengharuskan laptop ini diinstall Ubuntu Gutsy 7.10. Sayangnya, laptop ini tidak dapat diinstall Ubuntu dengan “cara biasa.” Ah, sedikit petualangan nih, pikir saya…

Sekedar petualangan ini ternyata berbuah puluhan kali restart, menunggu, googling, dan menggaruk2 kepala yang udah botak hahahha 😛

TVR856C 1

Masalahnya adalah:

  1. Live CD Ubuntu tidak bisa booting, hang sebelum instalasi karena tidak kompatibel dengan VGA onboard yaitu VIA UniChrome IGP.
  2. Live CD Ubuntu Alternate installer menampilkan tampilan teks yang kacau balau.
  3. WiFi sempat tidak terdeteksi (?)
  4. Bahkan setelah driver diganti “vesa”, resolusi terbaik yang dapat ditampilkan hanyalah 800×600 dengan monitor autodetection.
    Dengan manual setting, baru bisa menampilkan hingga 1024×768.

Santai aja, semua ada solusinya (kata Pak Purdi?) 😉

Peralatan dan sarana yang dibutuhkan:

  1. Laptop yang dimaksud (Axioo Neon atau laptop dengan chipset VIA hix hix…)
  2. Koneksi Internet, disarankan yang koneknya tinggal pakai kabel UTP/Ethernet misalnya Telkom Speedy. Kalo pake modem, wah nggak tau lagi deh.
  3. Keberanian, ketelatenan, dan kesabaran yang luar biasa… 🙂

Tutorial cara install…

  1. Cari/download CD Ubuntu Gutsy 7.10, Desktop edition, 32-bit PC version, Alternate installer.
  2. Tekan F6 untuk memunculkan kernel parameters. Ganti “quiet” dengan “vga=791” (tanpa tanda kutip) lalu tekan Enter. Setting ini untuk mengeset mode VESA/VGA text framebuffer menjadi resolusi 1024×768 16-bit. Jika belum cocok, coba juga “vga=788” untuk 800×600 atau “vga=785” untuk 640×480.
    Tip: Ada juga yang menyarankan menggunakan parameter “noapic”, tapi dalam kasus saya tidak berhasil.
  3. Tampilan instalasi harusnya muncul dengan normal, bahkan lebih lebar dari resolusi standarnya. Malah enak, kan? 🙂
    Install Ubuntu seperti biasa.
  4. Saat booting, kemungkinan Anda nggak bisa masuk ke GUI maupun GDM, karena VGA-nya gak cocok.
    Solusinya, reboot laptop lalu pada saat “GRUB loading, please wait…” segera tekan ESC, lalu pilih “… (recovery mode)” untuk masuk ke console.
  5. Ketik:
    dpkg-reconfigure xserver-xorg

    Pilih driver “vesa”, lalu pilih resolusi yang “nggak neko-neko”, misalnya 800×600.
    Untuk menggunakan resolusi 1024×768, jangan gunakan monitor autodetection, saat ditanya cara memilih monitor, pilih “Medium”, lalu pilih “1024×768 @60Hz”.

  6. Reboot (pencet Ctrl+Alt+Del atau ketik “reboot”), dan setelah itu harusnya Anda sudah bisa masuk GDM/GUI Ubuntu Gutsy yang nan aduhai itu lhooo…
    Tampilannya akan agak aneh karena tidak sesuai dengan rasio display laptop ini yang widescreen, but we’ll get to that on a sec, I promise! At least now “you’re in.” 😉
  7. Saat ini sepertinya Anda tidak bisa masuk ke TTY console mode teks (Ctrl+Alt+F1). Untuk itu, login aja dulu.
    Buka Applications -> Accessories -> Terminal.
    Ketik: gksu gedit /boot/grub/menu.lst
    Edit bagian “# defoptions=”, tambahkan “vga=791”. Contoh:

    # defoptions=vga=791 splash

    Simpan file lalu close Text Editor tersebut.

  8. Untuk mengaktifkan konfigurasi barusan, ketik di Terminal:
    sudo update-grub

    Reboot komputer.

  9. Driver WiFi di tempat saya awalnya tidak terdeteksi, lalu otomatis terdeteksi setelah saya melakukan update.
    Jadi, di step ini coba koneksikan laptop Anda ke Internet, lalu lakukan update total system ke package terbaru menggunakan System -> Administration -> Update manager. Reboot komputer dan seharusnya Anda sudah bisa menggunakan WiFi.
  10. Yang kurang lagi adalah display/screen resolution, yaitu menggunakan driver OpenChrome.
    Masuk ke Terminal, lalu ikut tutorial di halaman tersebut yang intinya seperti ini:

    sudo apt-get build-dep xserver-xorg-video-via
    sudo apt-get install subversion autoconf automake1.9 libtool
    svn checkout http://svn.openchrome.org/svn/trunk openchrome
    cd openchrome
    ./autogen.sh --prefix=/usr
    make
    sudo make install
  11. Driver OpenChrome sudah terinstall, tapi belum diaktifkan. Untuk mengaktifkannya, sebaiknya Anda reboot komputer dulu dan masuk ke modus “recovery mode” seperti sebelumnya. Ketik:
    dpkg-reconfigure xserver-xorg

    Saat konfigurasi, pilih driver “openchrome”, gunakan monitor autodetection, lalu pilih resolusi 1280×800 atau sesuai kemampuan laptop Anda.

  12. Di laptop ini, ada kemungkinan mouse cursor tidak ditampilkan dengan konfigurasi standar. Untuk memperbaikinya, edit file /etc/X11/xorg.conf:
    vim /etc/X11/xorg.conf

    Lalu tambahkan Option “SWCursor””true” di bagian Section “Device” sehingga menjadi seperti ini:

    Section "Device"
      Identifier "Generic Video Card"
      Driver "openchrome"
      BusID "PCI:1:0:0"
      Option "SWCursor" "true"
    EndSection
  13. Reboot komputer, kembali ke modus normal.

TVR 856C 2

Saat ini, laptop Axioo Neon TVR 856C kami cukup berjalan mulus dengan Ubuntu Gutsy Gibbons 7.10:

  1. Audio/sound/multimedia: WORKING PERFECTLY
  2. Video/graphics: WORKING PERFECTLY
  3. WiFi: WORKING PERFECTLY
  4. Ethernet: WORKING PERFECTLY
  5. DVD-RAM drive: WORKING PERFECTLY
  6. Webcam: ?
  7. 3D: I don’t care
  8. Compiz: Not working at all
  9. Memory card reader: Kayanya sih bisa…

Artikel lain:

P.S.: Untuk 3D, ada yang bilang kalo dengan menginstall DRM + XGL server bisa untuk mengaktifkan Compiz di VIA UniChrome IGP. Tapi, setelah berusaha untuk mengambil ‘jalur itu’, dan mumet, akhirnya saya memutuskan untuk nggak pake itu dulu deh…

P.P.S.: Informasi hardware Axioo Neon TVR-856C kami…

Like this article? Please share this article with others:

Password Management, The Best Practices

I found a very nice and thorough article about password management. I love it! 🙂

And it’s increasingly needed nowadays!!!

Password Management Best Practices

This document describes and justifies current password management best practices in an enterprise network. It is intended to offer reasoned guidance to information technology decision makers when they set security policy and design network infrastructure that includes passwords.

The document is organized as follows:

  • User authentication and passwords: Describes the objectives of user authentication, alternative technologies for authentication and why passwords continue to be the prevalent technology for identifying users.
  • Security threats: A list of the major security threats to password-protected network systems.
  • Human factors: How human behaviour affects password management.
  • Composition rules: Recommended rules for composing an acceptable password.
  • Changing and reusing passwords: Reasons and recommendations for periodic password changes, and for not recycling old passwords.
  • Secrecy: The need for keeping passwords secret, and recommended practices.
  • Intruder detection: Detecting and responding to security attacks.
  • Encryption: Using encryption to protect passwords in storage and in transit.
  • Synchronization: Reasons for and risks with keeping passwords on different systems the same.
  • User support: Password problems encountered by users, and how to securely resolve them.
  • Find out more: Other resources with information about password management.

Many applications depend on reliable user identification, also called authentication. Over the years, many technologies have been developed to support this requirements. Authentication technologies may be categorized as follows:

Authentication Factor Description Example
Secrets: Something you know secret information known only the user a password or PIN.
Tokens: Something you have a physical deviced possessed only be the user a token card or smart card.
Biometrics: Something you are a unique, measurable characteristic of the user voice print verification, fingerprint or retinal scan.

Generally, it is more secure to use multiple forms of authentication — e.g., a security token combined with a password.

These types of authentication may be further characterized as follows:

Characteristic Secrets Tokens Biometrics
Reliable identification? Good Very good Excellent
Requires client-side hardware No Sometimes Yes
Requires client-side software No Sometimes Yes
Typical deployment cost/user 0 $50 $100
Works with legacy systems Yes No No

Due to cost and compatibility with legacy systems, the most popular form of user authentication continues to be a secret password.

The remainder of this document discusses how to best manage passwords, to maximize security and minimize cost of ownership.

Passwords are simply secret words, or at best secret phrases. They can be compromised in many ways:

  • Users may write them down or share them, so that they are no longer really secret.
  • Passwords can be guessed, either by a person or a program designed to quickly try many possibilities.
  • Passwords may be transmitted over a network either in plaintext, or encoded in a way which can be readily converted back to plaintext.
  • Passwords may be stored on a workstation, server or backup media in plaintext, or encoded in a way which can be readily converted back to plaintext.

Each of these vulnerabilities make it easier for someone to acquire the password value, and consequently pose as the user whose identity the password protects.

Users in a large organization frequently have many passwords, each protecting their access to a different computer system. Users have some basic limitations, which limit what can be done in the context of secure password management. In particular, it is hard for most people to remember:

  • Complicated passwords.
  • Many different passwords.
  • Passwords that change frequently.
  • Passwords for systems that are used infrequently.

When people have trouble remembering their passwords, they do one or more of the following things:

  • Write down their passwords — and reduce security to the protection afforded by a piece of paper.
  • Forget their passwords — and require frequent assistance from a computer help desk organization to reset it.
  • Use very simple, easily compromised, passwords.
  • Reuse old passwords as often as possible.

Clearly, sound password management practices must take into consideration human limitations, to limit the above problems.

As outlined in (2), one of the primary weaknesses of passwords is that they may be guessed. While a human may give up after trying to guess ten or a hundred possible passwords, software such as Crack and L0phtCrack will happily try millions of combinations.

To combat password guessing attack, users should pick hard-to-guess passwords. One way to do this is to ensure that the set of all possible passwords is too large to search thoroughly, and then to eliminate probably guesses.

The number of possible password combinations is calculated by taking the number of legal characters in a password, and raising that number to the number of characters in the password. The possibilities for some likely combinations are shown below:

Legal  
characters 5 6 7 8 9 10
0-9 1.00e05 1.00e06 1.00e07 1.00e08 1.00e09 1.00e10
a-z 1.19e07 3.09e08 8.03e09 2.09e11 5.43e12 1.41e14
a-z,0-9 6.05e07 2.18e09 7.84e10 2.82e12 1.02e14 3.66e15
a-z,0-9,3 punct 9.02e07 3.52e09 1.37e11 5.35e12 2.09e14 8.14e15
a-z,A-Z 3.80e08 1.98e10 1.03e12 5.35e13 2.78e15 1.45e17
a-z,A-Z,0-9 9.16e08 5.68e10 3.52e12 2.18e14 1.35e16 8.39e17
a-z,A-Z,0-9,32 punct 7.34e09 6.90e11 6.48e13 6.10e15 5.73e17 5.39e19

Users must be required to choose their passwords from the widest possible set of characters, subject to the constraints of the systems where those passwords reside. For example, most mainframes do not distinguish between uppercase and lowercase, and only allow three punctuation marks (fourth row in the table above).

You must then set a policy based on the smallest permissible set of legal password values — for example: 10 billion. To draw from the above table, mainframe compatible passwords must be at least seven characters long to meet the requirement of at least 10 billion possible passwords.

A reasonable set of password rules, designed to ensure that the search space for all possible values is as reasonably large, and that passwords are not too easy to guess, follows:

  • To ensure that the search space is sufficiently large:
    • Passwords must be at least seven characters long.
    • Passwords must contain at least one letter, and at least one digit.
    • If this is compatible with your systems: passwords must contain both uppercase and lowercase letters, and at least one punctuation mark or other “special” character.
  • To eliminate easily guessed passwords:
    • Passwords must not be based on the user’s name or login ID.
    • Passwords must not be based on a dictionary word, in any language.
    • Passwords may not contain more than two paired letters (e.g. abbcdde is valid, but abbbcdd is not).

Over time, passwords may be compromised in many ways, including:

  • Users may share them with friends or coworkers.
  • Users may write them down, and they may then be exposed.
  • Passwords may be guessed, either by humans or security diagnostic software.
  • The servers that house passwords may be compromised, and their passwords acquired by an intruder.
  • The networks that passwords travel between a user’s workstation and servers that the user logs into may be compromised, and passwords may be recorded by an intruder during transmission.
  • Users may be tricked into providing their passwords to intruders via a social engineering effort.
  • The help desk may be tricked into giving an intruder a valid password.

To limit the usefulness of passwords that have been compromised, a best practice is to change them regularly. Common rules on many systems is to force users to change their passwords when they log in, if they have not been changed for an extended period (e.g., 30 or 60 days).

In general, users should be required to change their passwords regularly, at most every 90 days, and preferably more frequently.

For the same reasons, users should not reuse old passwords, as they may already have been compromised. Many systems support this by recording some representation of old passwords, and ensuring that users cannot change their password back to a previously used value.

When password history is enforced, users may figure out the number of passwords in their history file. As this number is normally 10 or fewer, a user who does not really wish to change his password when prompted to do so may make several consecutive password changes, and finally return his password to its original value.

To defeat such “smart” users, some systems also enforce a password rule that limits the number of password changes that a user may make in any given day. By forcing users to spend several days, users are less inclined to defeat the password history mechanism.

A better approach, though not yet available on many systems, is to simply maintain an unlimited number of entries in each user’s password history. Since disk storage has become very cheap, this approach is now feasible.

Passwords are intended to uniquely identify a user. As such, they must be secrets — known only to the user they identify.

Users frequently behave in ways that lead to password disclosure. In particular, users may:

  • Choose passwords which are easily guessed — so are not really secret.
  • Share their passwords with coworkers, friends or family.
  • Write down their passwords, and place the written password near their computer, or in an ostensibly private place like a wallet.

Corporate password management policy must forbid these practices, and allow for some negative consequence to users who violate these rules.

In addition, alternative mechanisms should be provided, to help users manage passwords without writing them down or sharing. Key among these mechanisms is password synchronization – which helps users to remember rather than write down passwords.

Many systems can detect an attempt by a user to log in with an incorrect password. If too many invalid attempts are made in a short period of time, it is possible that someone is trying to guess the user’s password.

To make password guessing attacks more difficult, many systems include an “intruder lockout” feature. This simply means that if N invalid attempts to login to the same account are made during T_1 minutes, then the account is disabled for T_2 minutes.

While this mechanism is effective against concerted attacks against a single account, they do not prevent an intruder from simultaneously trying to guess the passwords of many users. Also, intruder lockout can be used to carry out a denial of service — by systematically locking out many accounts, including administrator ones.

Because of these fundamental limitations, best practice is to limit enforcement of intruder lockout to:

  • Apply only to users, but exempt at least one administrator login.
  • Apply a high threshold for intruder detection — e.g., 5 failed attempts in 2 minutes.
  • Automatically clear the lockout quickly — e.g., after 10 minutes.

Passwords may be stored on user workstations or servers. They must be transmitted, in some form, from the user’s workstation to a server when the user first logs in, and possibly again later.

Not much can be done to enforce reasonable password encryption or hashing on existing server products. However, if you are responsible for developing a new server or application that manages its own passwords, it is best to store passwords using a well-known and trusted hashing algorithm, such as MD5 or SHA.

Passwords transmitted from a workstation to a server are similarly subject to the protocol developed by that server’s vendor. In general, mainframe, minicomputer and Unix servers tend to use no encryption by default, although strong encryption is available from most vendors as an add-on. If password security is important in your organization, and if you cannot trust the physical security of all communication media between a user and the systems s/he logs into, then you should seriously consider additional mechanisms to protect these login sessions.

Some workstations may “cache” passwords — and automatically provide them to servers when users need access. Such password caches also require strong cryptographic protection, and if this cannot be guaranteed are best avoided.

In some cases, the protocol provided by a vendor may encrypt passwords when they are used to login to a system, but not when a password change is transmitted. This happens with Oracle SQL*Net, for example. In these cases, if password management software is deployed, it is helpful for that software to implement its own encryption, beyond that provided natively by the system vendor.

Password synchronization is any process that helps users to keep the passwords that they use to log into different systems the same.

There is some debate as to whether password synchronization makes systems more secure, or less. The arguments are as follows:

  • Synchronization reduces security: If a single system is very insecure, then compromising that system will give an intruder the passwords for every other system in the network. This is prevented by requiring users to use different passwords on different systems.
  • Synchronization improves security: Users with many passwords have trouble remembering them, and consequently write them down. System security is reduced to the physical security of a piece of paper — i.e., almost no security at all.

In practice, it is hard or impossible to prevent users with unsynchronized passwords from writing them down. The two scenarios (synchronized vs. different passwords) therefore boils down to:

  • Synchronized passwords: as secure as the least secure system on the network.
  • Unsynchronized passwords: reduce protection to that provided by slips of paper.

Since most systems make at least some effort to protect their passwords, synchronized passwords are more secure. To mitigate the risk of a single system compromise being leveraged by an intruder into a network-wide attack, there are some password management guidelines to follow:

  • Very insecure systems should not participate in a password synchronization system.
  • Synchronized passwords should be changed regularly.
  • Users should be required to select strong (hard to guess) passwords when synchronization is introduced.

The bottom line is that a single, hard-to-guess, regularly changing password is more secure than multiple passwords, some of which may be easy to guess, some of which may not be changed regularly, and all of which may be written down.

Sometimes users forget the passwords they must type to log into network systems, or else type the wrong password too often, and trigger intruder lockout on their account. When this happens, users must call their help desk, and request assistance. The help desk process normally proceeds as follows:

  1. User experiences problems trying to log in.
  2. User calls the help desk, and may wait in a service queue.
  3. Support analyst asks the user for his name and a problem description.
  4. Support analyst asks the user for information to prove his identity.
  5. Support analyst compares this information with some on-line resource.
  6. If the user is authenticated, the support analyst may reset the password directly, or forward the problem to a special support person, who has the tools and privileges to reset the caller’s password.
  7. The user tries to log in with the newly assigned password.
  8. The user may be required to change the new password immediately.

Security problems

This process presents several security problems:

  • The support analyst may forget to authenticate the user at all.
  • Authentication information may not be available for the user.
  • Authentication information available to the help desk may be easily guessed, so that an intruder could compromise the process by claiming to be a user, and answering that user’s supposedly secret questions.
  • Many support analysts have the right to reset passwords.
  • Password resets may not be attributable to a support analyst, and consequently there is no accountability for who performed a password reset, when and how.
  • The support analyst knows the user’s new password at the end of the process, so it is no longer truly secret.

Mitigating controls

These problems can be overcome through:

  • Analyst training.
  • Ensuring that reliable authentication information is available for every user.
  • Providing an application proxy for analyst passwords resets — so that support analysts log into the application, and it resets passwords on their behalf. This can require user authentication, and provides for accountability and a reduced number of support staff with administrative system privileges.
  • Allowing users to reset their own forgotten passwords, after reasonable authentication.

User authentication

It is important to ensure that users who request a password reset, either by calling the help desk or using a self-service facility, are reliably authenticated. In practice, this means that:

  • Using security tokens or biometrics as a form of user authentication is more secure than asking personal questions.
  • Each user should be required to answer a unique set of questions for authentication.
  • Users should be prompted to answer truly personal questions.
  • If possible, users should be asked to answer different, randomly-selected questions every time they must authenticate.
  • Users should be able to update their own personal question and answer profiles. They can be authenticated to do so using one of their passwords.
  • Repeated failed attempts to authenticate as a user should trigger a security incident, and lock out the user’s account.
  • User Q&A profiles should include standards for minimum number of questions: e.g., 3, and minimum answer length and complexity — e.g., 10 characters per answer.

Some popular questions include:

  • Bank account or parts of a credit card number.
  • All or part of a social security number.
  • Expired car license numbers or old home address.
  • Driver’s license number.
  • Old telephone numbers.
  • Mother’s maiden name.
  • Nicknames of family, friends or pets.

Ideally, users should be able to define their own questions, in addition to answering standard ones.

This document was prepared by M-Tech, and reflects expertise with password management accumulated through many deployments of the P-Synch® Password Management System:
http://P-Synch.com/
http://MTechIT.com/

To find out more about automatic programs for guessing passwords, see Crack for Unix and L0phtCrack for Windows NT/2000/2003:
ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/
http://www.atstake.com/research/lc/index.html

The US federal government has password management standard — FIPS 112 at:
http://www.itl.nist.gov/fipspubs/fip112.htm

For a solution to logging into Unix systems without exposing passwords (or other data) on the network, refer to OpenSSH:
http://www.openssh.org

A more secure passwd program for Unix systems is npasswd – at:
http://www.utexas.edu/cc/unix/software/npasswd/

For general security news and information, visit:
http://www.securityfocus.com/.

Seriously!!!

Like this article? Please share this article with others: