WordPress.com was Down for A Moment

Not sure why I’m doing this, but well… WordPress.com, that probably mega blog hosting provider was down for a couple minutes (?) a few hours ago, at 25 August 2007 around 14:25 GMT+0700.

Original message:

Goshdarnit!

Something has gone wrong with our servers. It’s probably Matt’s fault.

We’ve just been notified of the problem.

Hopefully this should be fixed ASAP, so kindly reload in a minute and things should be back to normal.

Alright alright… Nothing to see here. Move on…

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!!!

Erlang: The Concurrent Programming Language

Thank you Orbitz for posting [Erlang vs.] Java and and Threads (Jetty):

The basic idea is, instead of using 1 thread per connection, since connections can last awhile, they use 1 thread per request that a connection has. The hope being, a connection will idle most of the time and only send requests once in awhile. The problem that they ran into is, a piece of software is using a request timeout to poll for data. So requests are now sticking around for a long time, so they have all these active threads that they don’t want. So to deal with this, they use a concept of continuations so the thread can die but the request still hang around, and then once it’s ready to be processed a thread is created again and the request is handled. So having all these requests hanging around that arn’t doing anything is no longer a problem.

ell, this begs the question, why are you using a dynamic number of threads in the first place if you are going to have to limit how many you can even make. If the problem, in the first place, is they have too many threads running, then their solution works only for idle threads doesn’t it? Being forced to push some of the requests to a continuation means they have applied some artificial limit to the number of threads which can be run. What happens then, when the number of valid active requests exceeds this limit? What then? Push active requests to a continuation and get to then when you have time? Simply don’t let the new requests get handled? If they want to to use threads to solve their problem then putting a limit on them seems to make the choice of threads not a good one. Too poorly paraphrase Joe Armstrong, are they also going to put a limit on the number of objects they can use? If threads are integral to solving your problem, then it seems as though you are limiting how well you can solve the problem.

This also got me thinking about other issues involving threading in non-concurrent orientated languages. Using a COL (Concurrent Orientated Language) all the time would be nice (and I hope that is what the future holds for us). But today, I don’t think it is always practical. We can’t use Erlang or Mozart or Concurrent ML for every problem due to various limiting factors. But on the same token, using threads in a non-COL sometimes makes the solution to a problem a bit easier to work with. At the very least, making use of multiple processors sounds like a decent argument. But writing code in, say, java, as if it was Erlang does not work out. I think the best one can hope to do is a static number of threads. Spawning and destroying threads dynamically in a non-COL can be fairly expensive in the long run and you have to avoid situations where you start up too many threads. I think having a static number of threads i a pool or with each doing a specific task is somewhat the “best of both worlds”. You get your concurrency and you, hopefully, avoid situations like Jetty is running into. As far as communication between the threads is concerned, I think message passing is the best one can hope for. The main reason I think one should use message passing in these non-COL’s is, it forces all of the synchronization to happen in one localized place. You can, hopefully, avoid deadlocks this way. And if there is an error in your synchronization, you can fix it in one spot and it is fixed everywhere. As opposed to having things synchronized all over the code, god knows where you may have made an error.

…although it seems not all his readers corroborate with what he meant by “concurrent oriented languages”.

I strongly concur that languages *such as* Erlang (I’m saying such as, because Erlang got the concept right, and other languages /platforms/technologies may follow) will lead or at least make the transition into the future easier.

What the hell is Erlang anyway? Well:

Joe Armstrong had fault tolerance in mind when he designed and implemented the Erlang programming language in 1986, and he was subsequently the chief software architect of the project which produced Erlang/OTP, a development environment for building distributed real-time high-availability systems. More recently Joe wrote Programming Erlang: Software for a Concurrent World. He currently works for Ericsson AB where he uses Erlang to build highly fault-tolerant switching systems.

Erlang is a concurrent functional programming language. Basically there are two models of concurrency:

  • Shared state concurrency
  • Message passing concurrency

Virtually all language use shared state concurrency. This is very difficult and leads to terrible problems when you handle failure and scale up the system.

Erlang uses pure message passing concurrency. Very few languages do this. Making things scalable and fault-tolerant is relatively easy.

Erlang is built on the ideas of:

  • Share nothing. (Process cannot share data in any way. Actually, this is not 100% true; there are some small exceptions.)
  • Pure message passing. (Copy all data you need in the messages, no dangling pointers.)
  • Crash detection and recovery. (Things will crash, so the best thing to do is let them crash and recover afterwards.)

Erlang processes are very lightweight (lighter than threads) and the Erlang system supports hundreds of thousands of processes.

It was designed to build highly fault-tolerant systems. Ericsson has managed to achieve nine 9’s reliability [99.9999999%] using Erlang in a product called the AXD301. [Editor’s Note: According to Philip Wadler, the AXD301 has 1.7 million lines of Erlang, making it the largest functional program ever written.]

While people are talking about 16-, 32-, 64- bits… And limit their “stuff” (whatever it is, threads, objects, RAM, …) accordingly, in Erlang there is no such hard limit.

Erlang processes can grow as big as it wants, provided you give it *enough resources*. Which means, the *same* Erlang program can run on 1 node on a single workstation, or on 1,000 servers spread across different buildings (or continents). The programmer doesn’t care anyway.

How much limited RAM? How much sockets can be open? etc. doesn’t depend on the programmer, and hopefully the programmer won’t need to care about it. Who will care about it is the one who’ll be deploying and running the Erlang program.

Most people still think of programming (and worse, think of Erlang) as procedural languages, then built things on top of it including threading… a threading framework.

Erlang on the other hand is sort of kernel (hence why it’s called a VM, not simply an interpreter but a real VM that manages processes the way a OS manages OS processes). Every function runs on different processes. A process may run in its own Erlang VM node, a different VM node in the server, or on another server. The program doesn’t really care that much (it can care, but doesn’t have to use a “distributed framework” the way other languages do.)

More information about this exciting language:

Update: Some frameworks, in particular Message Queueing systems (e.g. Microsoft’s and Sun Java’s), I think got it right… but on a more complicated, heavyweight level. Erlang/OTP is, under the hood, a message queueing system but much lighter on the CPU… and much lighter on the programmer brain overhead. 😉

Update 2: As of now I still don’t know what OTP stands for 😉

Sculpting girl

Everybody Is A Programmer

Sculpting girl

When people ask me, what do you do? And I probably answer… “I’m a programmer.”

So they ask about computers, the Internet, e-mail, et cetera…

Great!

But the truth is… Everybody in this world is a programmer.

I’m not talking in the narrow sense, and I’m not talking in the too much broad/generic sense that doesn’t apply specifically.

I’m talking in the true sense, in that there’s no difference between a simple programmer and a computer programmer.

Confused?

Well, it may not be coming to you now. But I’ll guarantee it myself. 🙂

Ubuntu, Muslim Edition

Buat yang Islam, dan pengen komputernya juga terisi hal-hal yang bertema Islami… Baru nemu, keren juga.

Dari udienz:

Bismillahirrohmanirrohiem, Assalamualikum

Di Linux kita bisa mengoprek system sesuka kita (tp harus jadi root), hm… kemarin iseng iseng lihat ubuntu-me via website resminya, dan sempat kecewa sih sebenarnya karena tidak ada perubahan signifikan dari Ubuntu , cuma tambah beberapa program aja… (mungkin butuh kontribusi kita kali ya…)

oke akhirnya saya pengen membuat Ubuntu feisty saya menjadi Ubuntu-ME, pertimbangan:

1. ribet install ulang

2. males konfigurasi ulang

3. ga ada waktu lagi…

gimana caranya biar ubuntuku jadi Ubuntu-ME???

seperti yang telah kita ketahui Ubuntu-ME menambahkan program-program tambahan di distro tersebut, yaitu ubuntume-artwork, wcc (Web Content Control tool), islamiccal, zekr, minbar. perincianya adalah sebagai berikut:

1. Ubuntu-Me artwork adalah paket yang menyediakan theme, splash screen, dll

Gambar.1 Wallpaper Ubuntu-Me

Gambar 2. Tampilan Log-In

Gambar 3. Alternatif Tampilan Log-In

Gambar 4. splash screen

Gambar 5 Tampilan Theme

2. wcc (Web Content Control tool), cocok buat yang mau jaga si kecil dari situs porno dan tampilan seronok

Gambar 6 Pengaturan

Gambar 7 ups…. ada yang mau ke situs PlayBoy

3. Islamic Calender, kalo yang ni ga ussah di jelasih semua pada udah tau lah….

4. zekr, ini yang aku suka, dia menampilakan text Al-Qur’am secara lengkap dan bagus

Gambar 8 Tampilan Zekr

5. minbar, masih ingat program Athlan di *indows??? mirip seperti ini… ni program cocok buat pelupa, coz dapat mengingatkan kita waktu sholat

Tertarik?

Untuk instalasi dan info lengkap baca Feisty jadi Ubuntu Muslim Edition.

Best Ubuntu Tutorials by Christer Edwards

I just found a very nicely packed with useful information site for Ubuntu called Ubuntu Tutorials, created by Christer Edwards.

Among the top Ubuntu tutorials he posted include:*

I found his site while searching for a way to install Thunderbird 2.0.0.5. And hey, he also have tried Ubuntu 7.10 Gutsy Gibbons (pre-release).

If you’re not aware of Ubuntu, visit Ubuntu web site. Summary: Excellent free operating system. 🙂

I’ve also written some articles about Ubuntu.

* As of this writing.

Makan Pelan + Mengunyah itu *Sangat* Penting!

Anda sering atau sedang mengalami masalah kesehatan? Obesitas, diabetes, maag, diare, dan lain-lain?

Cobalah tips yang sangat sederhana ini: mengunyah makanan dengan pelan pada saat makan, jangan tergesa-gesa.

Alasannya? Artikel Irvan Tambunan ini sangat bagus:

Menurunkan berat badan. Menurut penelitian, saat makan dengan pelan, kita mengonsumsi beberapa kalori. Faktanya, cukup untuk mengurangi 10 kilogram dalam setahun tanpa melakukan sesuatu
apapun. Otak memerlukan waktu 20 menit untuk menyadari bahwa kita sudah kenyang. Makan dengan pelan, menyadari bahwa kita sudah kenyang, dan kita dapat berhenti makan tepat waktu. Jadi, untuk mengurangi berat badan, kita harus makan dengan pelan.

Menikmati makanan. Ini merupakan alasan yang sangat masuk akal. Saya teringat dengan kejadian yang dialami teman saya.Karena makan dengan cepat, dia sempat tersedak saat makan. Wah, tentu hal ini sangat menyiksa. Suasana makan pun terasa tidak enak lagi. Dengan makan pelan, kita dapat merasakan nikmatnya rasa makanan yang kita santap.

Pencernaan yang baik. Jika kita makan dengan pelan, kita dapat mengunyah makanan secara sempurna. Saya teringat pelajaran di SD bahwa kita harus mengunyah makanan sebanyak 32 kali sebelum ditelan. Ini dapat membuat pencernaan kita menjadi lancar. Karena sudah dikunyah dengan sempurna di dalam mulut, usus halus tidak perlu bersusah payah menguraikan makanan lagi untuk menyerap sari-sari makanan. Dengan ini, pencernaan menjadi lebih baik.

Mengurangi stres. Saat makan dengan pelan, otomatis konsentrasi hanya tertuju pada makanan. Kita tidak akan berpikir pada masalah yang sedang dihadapai. Dengan demikian, masalah yang dapat membuat kita stres akan hilang sementara. Ada beberapa orang yang percaya bahwa salah satu cara mengurangi stres adalah dengan makan. Menurut saya, hal ini ada benarnya juga. P

Melawan terhadap fast food dan fast life. Gaya hidup instan membuat kita sering untuk memakan makanan cepat saji. Sebut saja restoran fast food yang terkenal seperti McDonald’s. Hal ini membuat hidup kita menjadi tidak sehat, penuh dengan stres, dan tidak menyenangkan. Saya menyarankan kepada anda agar tidak sering mengunjungi restoran tersebut. Sebisa mungkin untuk dihindari. Makanlah di restoran yang sehat, atau lebih baik masaklah makanan anda sendiri. Selain lebih sehat, memasak dapat memberikan kesenangan kepada kita. D

So?

Kalo masih nggak percaya, coba kunjungi Slow Food Manifesto.

What The Movies Taught Me About Philosophy, Episode I

Sometimes you learned enough just by watching enough movies…

Memento
taught me that every ending has a beginning, but you can never be sure what caused that beginning.
Tomorrow Never Dies
taught me that you can always predict the future if you made sure the it will happen.
Robots
taught me that tiny things may make big changes.
Sky Captain and The World of Tomorrow
taught me that you can not only predict what happens in the future, but you can also schedule it.
The Talented Mr. Ripley
taught me that nobody has capability, or even willingness, to accept the truth.
Crash
taught me everything.
The Shawshank Redemption
taught me that you’re the only person who knows your plans better than anybody else.
Blast from The Past
taught me that lies heal.
Pleasantville
taught me that imperfections make the world the perfect place to perfect ourselves.
The Butterfly Effect
taught me that however bad your situation is right now, it always could have been worse had you tried to do it differently in the past.

Titanic
taught me that if loving someone is wrong, you better make sure you’d still be alright when you lose it.

Serendipity
taught me that nobody cares about how good you are, only what they feel.
Alfie
taught me that even if you can control the world, but you can never control how the world will respond to you.
Pay It Forward
taught me that you can never change, much less fix, anyone. But you can make the world a better place for people to blame others.

Life is Beautiful (La Vita è bella)
taught me that you can choose to be a special person whenever you want, but you should not expect others to respect the choice you made.

The Secret
taught me that atheists now has a better way of saying that they’re atheists.
Trivia: If David Heinemeier Hansson were to direct a movie, it would have taught me that 20% of the world’s goodness accounts for 80% of evil.

Credits: Thanks to magenSaa yang suka nonton & ditonton 😉

Hedonism

The Human Heart, So Many Things to Learn About

Hedonism

there are so many things I need to learn ………!!

wow, I can’t believe it.

waktu saya masih SMA, saya pikir saya cuma akan cukup dengan belajar teknologi komputer

waktu saya menjelang lulus SMA sampai kuliah, saya pikir saya sangat membutuhkan persahabatan, bidang psikologi, dan hal2 yang berhubungan dengan hubungan manusia JUGA, di samping komputer

koma……

untuk sekian lamanya, hanya itu yang ada dalam pikiran saya

entah kenapa, lama2 saya menjadi *diperlukan*… dalam artian bahwa diperlukan itu tidak 100% murni keinginan saya, untuk mempelajari hal-hal lain.

ada beberapa yang memang ingin saya pelajari, misalnya tentang fotografi, film, musik, dan seni. juga tari. (ya semua tadi seni sih) dan sedikit banyak kesehatan, baik kesehatan fisik, emosi, maupun spiritual. (spiritual di sini bukan berarti ‘religius’ dalam hubungannya dengan agama, tapi lebih kepada spiritual dalam konteks kebatinan)

tapi ada hal-hal lain yang tidak 100% ingin saya pelajari

misalnya bisnis
finansial
desain interior, eksterior, arsitektur
ergonomy
neuro linguistic programming dan semua hal yang secara frankly speaking
adalah mengkompensasi keterbatasan pikiran dan emosi manusia
emosi, emosi, dan emosi
dan juga…….

hukum 🙂

I like [all these] a lot 🙂

so many things to learn, so many tools to use, and in some ways so little time.

so many experiences that will come to me, whether explicitly requested or they just come to me (“the Secret Law of Attraction“, remember?)

so many consequences to overcome… all because I need to be responsible of all my actions, and non-actions…

………

the probably last but most essential point of my soul searching journey, is …

HEART.

few people (I guess) know what it is.
few people know what it actually stands for.
even fewer know what’s inside other people’s hearts.

most people, probably including me, will never know completely what they really want to know about it, even until their deaths

yang bisa kulakukan sekarang hanyalah menduga
judging, assuming, mengira-ira, mengambil kesimpulan, mencari hipotesis
berdasarkan previous beliefs, assumptions, experiences, dan observations

….

Kesimpulan sementara, do you want to know?

Gw masih sedih.
Sedih karena ‘heart’ isn’t like what I expected…

Saya kecewa dengan hatiku sendiri.
Dan sampai batas tertentu dan dengan pemahaman dan rationale tertentu, saya juga kecewa dengan hati orang lain.

(Explanation: ‘heart’ atao ‘hati’ yang saya maksud di sini bukan hati dalam pengertian sempit seperti hati-nya orang yang lagi jatuh cinta, tapi lebih ke pengertian yang lebih luas di mana hati adalah esensi dari jiwa seorang manusia, _terlepas_ dari emosi atau perasaan)

Analogically philosophically illustratively, terlalu banyak “helmet” yang dipakai untuk melindungi heart tersebut.

Helmet ego…
Helmet jabatan, pangkat…
Helmet status sosial…
Helmet status ekonomi…
Helmet gengsi atau ja-im…
Helmet ketidakmauan…
Helmet public figure…
Helmet harga diri, harkat, martabat…. (yang saya sendiri belum pernah
buka kamus untuk mengetahui artinya apa kata2 tersebut)
Helmet asumsi
Helmet kultural
Helmet tradisi keluarga, tradisi desa, tradisi bangsa dan
tradisi-tradisi lainnya
Helmet negara
Helmet agama…………… (auch!)
Helmet gender 😛

Intermezzo: Gw barusan mendengar kisah “unik” di mana pada sebuah konferensi internasional, wakil parlemen (?) dari Prancis melakukan walk out dari pertemuan, dikarenakan seorang pengusaha Perancis yang hadir di situ menggunakan bahasa Inggris untuk menyampaikan materinya. Mungkin ini yang dinamakan “helmet bahasa”? (Penjelasan: pejabat tersebut hanya suka kalau mereka menggunakan bahasa Prancis alias French) Gw sendiri nggak tahu pasti mana konferensi yang dimaksud dan beritanya seperti apa, so ini hanyalah desas-desus. Mungkin kalo suatu saat gw nemu peristiwa dimaksud, ntar gw bahas lg lebih detail

back to sebelum intermezzo: (kayak lirik lagu aja hahah)

Kenapa sih ada helmet? (helmet di sini tentu dalam artian filosofis, bukan secara fisik berbentuk helm yang sekadar helm non-standar yang masih banyak dijual itu sudah tidak laku lagi karena polisi sudah nggak mengakui fungsi dari helm non-standar. kasihan deh penjual helm?)

Helmet untuk melindungi apa, tentu saja…… dari luka. Dari luka hati. Untuk melindungi hati agar hati tersebut tidak terluka.

apakah jika Anda dihina, hati Anda terluka?
jika Anda dijelek-jelekkan orang, hati Anda terluka?
Anda dilecehkan, hati Anda terluka?
Anda dituntut ke pengadilan, hati Anda terluka?
Anda dirampok, hati Anda terluka?
Anda dikhianati teman Anda, hati Anda terluka?

Apabila pikiran Anda sesuai dengan perkiraan saya, maka Anda akan jawab “pasti dong!”, “tentu saja”, ato minimal, “iya juga sih”.

Saya sendiri, menjawab “TIDAK” pada semua pertanyaan di atas. Why?

Apabila saya dihina, ‘harga diri’ saya yang terluka
Apabila saya dijelek-jelekkan orang, ‘reputasi’ saya yang terluka
Apabila saya dirampok, ‘finansial’ saya yang terluka
Apabila saya dikhianati, ‘kepercayaan saya terhadap orang lain’ yang
terluka

dan seterusnya

Hati saya akan tetap seperti sediakala.

Karena hati merupakan satu hal yang terpisah dari hal-hal tersebut, helmet-helmet tersebut yang bersifat emosional, duniawi, material, intelektual, bahkan religius……..

Bagaimana cara membuktikannya?

Andai saya dirampok, lalu saya amnesia, apakah “hati” saya tetap terluka setelah itu?
Andai saya dijelek-jelekan, lalu saya amnesia, apakah “hati” saya tetap terluka setelah itu?
Andai saya dikhianati, lalu saya amnesia, apakah “hati” saya tetap terluka setelah itu?

Kalau memang hati saya terluka gara-gara dirampok atau hal-hal yang lain tadi, kenapa bisa hilang begitu saja hanya gara-gara amnesia?

Bukankah amnesia adalah kehilangan ingatan (sementara?) yang hubungannya dengan otak? Dengan pikiran?

Mungkinkah hati mengalami amnesia? Amnesia hati?

(this part is blanked intentionally)

…………………..

apakah yang terdapat di dalam hati?

Saya bilang bahwa hati Anda tidak mungkin amnesia. Pikiran Anda boleh amnesia. Google mungkin saja suatu saat (meski tidak kita harapkan) datacenternya kacau balau dan semua data pribadi Anda termasuk e-mail, kartu kredit, dan password Anda kebobolan… (bukan pertama kali terjadi) Tapi hati Anda, hati manusia yang sebenarnya tidak mungkin
amnesia.

Itu kesimpulan sementara saya saat ini.

Bagaimana mengujinya? Tentu saja semua hipotesis akan diuji terlebih dahulu untuk membuktikan kebenaran pernyataannya.

Saya tetap akan menggunakan metode amnesia tadi.

Ambil contoh seseorang yang suka berbuat baik, suka menolong, suka dermawan…
Lalu dia mengalami amnesia.
Setelah itu, dia lupa segalanya. Dia lupa teman2nya, lupa berapa jumlah uang di banknya, dan lupa namanya sendiri, bahkan orang tua dan anak2nya.

Pertanyaannya: Apakah setelah itu dia tetap suka berbuat baik, suka menolong, dan suka dermawan?

Pembuktian kedua, sebaliknya:

Ambil contoh seseorang yang suka mencuri, suka berbuat jahat, suka menyakiti orang lain……
Lalu dia mengalami amnesia.
Sama, dia juga lupa segalanya, lupa semua tindakan kejahatannya, lupasemua catatan kriminalnya di polisi… Dan anggap saja dia cukup beruntung sehingga tidak ada lagi polisi yang mengenali dia, mungkin dia terdampar di negara lain.

Pertanyaannya setara: Apakah setelah itu dia tetap suka berbuat jahat?

Sejujurnya, saya belum pernah melakukan pembuktian seperti itu… tapi saya mempunyai penalaran secara intuitif bahwa dalam kedua pertanyaan di atas, jawabannya adalah “YA, orang tersebut akan bersikap sama seperti sebelum dia amnesia.”

So, kesimpulan sementara saya adalah… hati tidak dapat amnesia.

……

Hati tidak terpengaruh oleh negara. Hati tidak akan terpengaruh oleh teman, uang, barang, agama, dan apa pun juga ……..

kecuali jika pemilik hati yang mengizinkannya.

Spiderman 3

Semi-intermezzo: Saya jadi teringat film Spiderman 3, di mana sang “stering” utama yaitu Peter Parker, seolah-olah menjadi jahat setelah mengenakan jubah hitam yang entah dari mana asalnya. Perubahan si Spiderman begitu dahsyat, sampai-sampai akhirnya dia memukul Mary Jane, kekasihnya sendiri yang sangat dicintainya. Tapi dia kembali seperti sifatnya sediakala yang baik dan lembut (dan naif, tidak sensitif terhadap perasaan cewek, hehe 😉 manakala dia berhasil melepaskan diri dari jubah hitam yang lengket2 tersebut…

Lain halnya dengan sang reporter antagonis yang saya lupa namanya (update: Harry Osborn), karena sudah berniat jahat bahkan sebelum tercemari oleh jubah hitam yang sama. Begitu mendapatkan kekuatan jubah hitam, maka dia menjadi semakin jahat. Dan begitu sayangnya dia dengan jubah jahatnya itu sampai-sampai pada saat Spiderman menghancurkan sang jubah… sang reporter pun rela ikut ke dalamnya!

How long can any man fight the darkness, before he finds it in himself?

Sebuah moral cerita yang indah bukan…?

So kalo saya ngasih nilai review 5 stars buat film Spiderman 3, what made it 5 stars is not the action & visual effects… but the deep philosophical meaning it expresses. 🙂

Tanpa helmet-helmet sekali pun, hati yang sebenarnya tidak akan mungkin terluka.

Justru menurut saya, helmet-helmet itu tadi lah yang melukainya. Helmet-helmet itu tadi lah yang mengubah hati… karena pemilik hati mengizinkan hal-hal yang berhubungan dengan helmet-helmet tadi untuk mengubah hatinya, dan mungkin, perlahan sedikit demi sedikit, melupakan jati diri hatinya yang sebenarnya yaitu hati yang murni, penuh kasih sayang yang tulus, yaitu hati nurani manusia secara universal.

….

Hearts can change. The only person who can change a person’s heart is, themself.

Emosional

Emosi merupakan sifat bawaan manusia. James Gwee, motivator bisnis ternama dari Singapura, mengatakan:

Customer yang sedang emosi tidak akan bisa menerima penyelesaian masalah.

Singkatnya, dalam keadaan emosi manusia tidak bisa berpikir dengan jernih. Hal ini terjadi baik pada laki-laki dan terutama perempuan.

Teman-teman saya sering tidak percaya bahwa saya berusaha untuk bersikap berbalik dengan mood saya saat itu. Saya sendiri dalam menilai orang, berusaha memperhatikan mood orang tersebut, dan bukan hanya sikapnya.

Ada prinsip mendasar dari “keanehan” tersebut.

James Gwee, lagi-lagi pernah mengatakan dalam sebuah seminar bisnisnya:

Apabila Anda melakukan A, Anda akan mendapatkan A. Apabila Anda menginginkan B, Anda harus melakukan B. Tidak bisa Anda menginginkan B tapi tetap melakukan A. Karena antara keinginan Anda dengan usaha Anda tidak sinkron.

Bila seseorang bahagia dan dia tersenyum, itu wajar!
Bila seseorang sedih dan dia cemberut, itu juga wajar!
Bila seseorang kesal dan dia marah-marah, itu sangat wajar!

Dalam sebuah hubungan, juga sama…

Bila di dalam “hati” seseorang ada cinta buat Anda, dan dia selalu memperlakukan Anda dengan spesial, itu biasa!
Bila orang itu membenci Anda dan dia selalu berpikir negatif tentang Anda, itu juga biasa!

Entah kenapa, sebagian orang tidak menyadari perbedaan antara sikap seseorang, dengan pendorong orang tersebut bersikap seperti itu. Pendorong sendiri sering disebut dengan istilah “motivasi.” (disclaimer: ada juga yang mengaitkan motivasi dengan tujuan yang ingin dicapai, tapi bukan itu yang saya maksud di sini, melainkan penyebabnya.)

Kalau mendengar kata “motivasi”, mungkin orang berpikir macam-macam, mulai dari bisnis, MLM, sampai belajar untuk ujian. Namun, yang perlu diperhatikan adalah, motivasi mendorong kita untuk melakukan sesuatu.

Motivasi di sini dalam artian luas, bahkan emosi juga termasuk “motivasi”.

Contoh saja, orang marah-marah, juga karena adanya motivasi atau pendorong. Motivasinya, tentu saja adalah emosi dia yang sedang kesal. Akan sangat aneh rupanya, jika orang sedang kesal tapi dia tertawa terbahak-bahak. Atau jika hatinya sedang bahagia tapi malah marah-marah.

Namun, yang ternyata jarang disadari orang, adalah motivasi menutupi niat sebenarnya dari sikap seseorang.

Analoginya adalah jika Anda menaruh sebuah gerobak di atas bukit yang menurun, maka gerobak tersebut akan berjalan dengan sendirinya tanpa Anda harus berbuat apa-apa. Ini beda dengan gerobak yang berada di tanah datar, atau lebih hebatnya lagi adalah gerobak yang berada di lembah, dan Anda harus berusaha mendorongnya ke atas sambil melawan gravitasi.

Ini alasan mengapa saya berusaha menghargai seseorang lebih karena niatnya daripada sikapnya.

Sekedar ilustrasi, misalnya ada seseorang yang Anda minta dari Kediri ke Surabaya. Dia sampai dalam waktu 3 jam, naik bus. Anda seharusnya puas. Tapi, andai saja, ternyata keadaannya saat dia hendak berangkat tidak seperti itu. Ada hujan badai, sehingga dia basah kuyup. Tidak ada bus yang lewat setelah ditunggu lama. Dan dia kecopetan.

Apakah dia tetap berangkat ke Surabaya?

Bila dia membatalkan niatnya, itu wajar. Karena motivasinya sudah dilemahkan oleh berbagai kesulitan yang dia hadapi. Tanpa motivasi, hanya tertinggal niat. Dan tanpa niat, orang tak akan melakukan apapun.

Namun, mungkin juga dia tetap kukuh menjalankan niatnya. Dia berusaha mengayuh sepeda dari Kediri ke Surabaya. Terlepas dari berhasil tidaknya, dia pantas diberikan penghargaan atas usahanya ini.

Emosi adalah motivator yang sangat besar, namun jarang diberi perhatian.

Apakah Anda akan memberi penghargaan bagi orang yang suka tersenyum?

Bagaimana dengan orang yang hatinya sedang sangat kalut tapi dia berusaha tersenyum untuk Anda? Akankah Anda memberinya penghargaan?

Pernahkah (atau seringkah?) Anda mendengar: “Maklum dong, waktu itu aku kan lagi emosi. Sekarang aku udah gak marah lagi…”

Atau mungkin: “Waktu itu aku kan lagi senang. Sekarang aku lagi marah nih…!!”

Atau mungkin: “Waktu itu aku kan lagi suka ama kamu, tapi sekarang…”

Anda mungkin bisa melihat niat seseorang yang sebenarnya di balik sikap dan motivasinya… Sikap seseorang bisa berubah dalam hitungan detik. Motivasi bisa berubah seiring waktu.

Niat seseorang, sebagaimana pun sulitnya untuk dicari, juga bukanlah suatu hal yang konstan, bisa berubah-ubah, tidak jauh berbeda dengan emosi manusia itu sendiri.

Everybody always starts a mistake at all times. They just don’t know when, they will realize each mistake they started. In the mean time, they’re simply enjoying it… 🙂

Artikel-artikel yang relevan berikut ini juga menarik lho: